What methods of the Azure .NET SDK EventHubClient instance are thread safe?
I am writing code that will post messages from multiple threads to the Azure Event Hub in C # using the EventHubClient . The documentation for the EventHubClient contains a fairly standard boiler plate.
"Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe."
No further documentation on thread safety in any of the four send methods I would most expect to be thread safe. If I believed that the dispatch methods were not thread safe, I would end up creating a new EventHubClient instance every time I wanted to send a message. Since the underlying tcp connection is obviously reused, if no steps are taken, this may not have too much overhead. Similar problems arise with partitioned senders , although given that there is an asynchronous creation method, they can have their own AMQP connection.
Are some, if not all, of the EventHubClient instance methods safe, despite the documentation?
And for any azure people, could this be clarified in the documentation? This kind of documentation issue (assuming it's not correct as it seems) seems to affect the Azure table and is also generally common in MSDN docs. As far as the EventHub is concerned, this goes against the clear description of Kafka's flow security and AWS Kinesis at least does not explicitly mark everything as insecure. I didn't find EventHubs in the open source SDK part, so I couldn't test myself.
source to share
TL; DR :
- All critical execution operations in the .NET SDK are thread safe.
- Create object
EventHubClient
once and reuse
History
The ServiceBus SDK provides two templates for creating senders:
- The main
- Additionally
For basic version - developer will use EventHubClient.CreateFromConnectionString () directly and don't worry about messagingFactory management (gu connection). The SDK will handle reuse of MsgFactory in all EventHubClients if the connection string is the same.
For the advanced developer who needs a little more control at the connection level, the SB SDK provides MessagingFactory.CreateFromConnectionString (), and from this create an EventHubClient instance.
In general, none of the EventHubClient instance methods are guaranteed to be strictly thread safe (although they are today). If all you do is just send (differentMessages) across multiple threads - it's thread safe to receive. The reason for this is that implementing an absolute thread-safe library will always only have a significant performance penalty - I believe this is chosen as the default template for .Net.
Creating a new instance EventHubClient
in each component to send dispatch messages is the default template - and the ServiceBus SDK will take care of reusing the underlying MessagingFactory that reuses the same physical socket.
If you're looking for real-world high throughput scenarios, you should strategize about creating multiple MessagingFactory objects and then creating EventHubClient each. However - make sure you have already increased the Thruput blocks for your EventHub in the Portal before attempting this, as the default is only 1 MBPS - cumulative of all 16 partitions.
Also, if the submission template you are using is Partitioned Senders - they will all also use the same underlying MessagingFactory - if you create all senders from one instance of eventHubClient (. CreatePartitionedSender ()).
NTN! Sree
source to share