Какие методы экземпляра EventHubClient пакета SDK для Azure .NET являются потокобезопасными?

Я пишу код, который будет публиковать сообщения из нескольких потоков в Azure Концентратор событий на C # с использованием EventHubClient. Документация для EventHubClient содержит довольно стандартный шаблонный лист.

«Любые общедоступные статические (общие в Visual Basic) члены этого типа являются потокобезопасными. Не гарантируется, что любые члены экземпляра будут потокобезопасными».

Дополнительная документация по безопасности потоков ни в одном из четыре отправить методы Я больше всего ожидал бы быть потокобезопасным. Если бы я считал, что методы отправки не являются потокобезопасными, я бы создавал новый экземпляр EventHubClient каждый раз, когда хотел отправить сообщение. Поскольку базовое tcp-соединение очевидно используется повторно, если не будут предприняты шаги это может не иметь слишком больших накладных расходов. Подобные проблемы возникают с разделенными отправителями. хотя, учитывая, что для его создания существует асинхронный метод, они вполне могут иметь собственное соединение AMQP.

Являются ли некоторые, если не все, методы экземпляра EventHubClient потокобезопасными, несмотря на документацию?

И для кого-нибудь из Azure можно было бы уточнить это в документации? Подобная проблема с документацией (при условии, что это неверно, что кажется вероятным), похоже, влияет на таблицу Azure и обычно встречается в документы MSDN. Что касается EventHub, это контрастирует с четким заявлением о безопасности потоков в Kafka и AWS Kinesis по крайней мере явно не помечает все как небезопасное. Я не нашел EventHubs в части SDK с открытым исходным кодом, поэтому не мог проверить себя.


person cacsar    schedule 12.11.2014    source источник


Ответы (1)


person    schedule
comment
Не могли бы вы подробнее рассказать о деле с разделенными отправителями? Может ли он создать соединение AMQP непосредственно с разделом, или его единственная цель - переопределить разделитель на основе хэша? Если последнее, есть ли причина для асинхронного вызова? Я бы не ожидал, что библиотека будет полностью потокобезопасной, но если Send в настоящее время является потокобезопасным и построен на основе поточно-ориентированной фабрики обмена сообщениями, она просто помечена как не потокобезопасная, чтобы каким-то образом оставлять будущие параметры открытыми? - person cacsar; 18.11.2014
comment
Отличный вопрос. PartitionedSender не создает прямое соединение amqp с разделом. Каждый отправитель ServiceBus сначала обращается к шлюзу svc и разрешает внутреннюю роль, с которой он разговаривает. Единственное преимущество / оптимизация разделенного отправителя, которое я могу себе представить, это то, что шлюз не должен будет вскрывать сообщение amqp (аннотации msg - ›стоимость десериализации - если это было сделано правильно) и извлекать ключ раздела и вычислять хэш для найти правильный раздел. Асинхронный - чтобы сохранить его расширяемым (для будущих оптимизаций, чтобы найти раздел на клиенте и fwd) - что на сервере уже имеет случай 4 Темы. - person Sreeram Garlapati; 22.11.2014
comment
Должен сказать, что это достаточно приличный ответ. Когда придет время пересмотреть API производителя или предоставить более дружелюбный, я бы попросил вас взглянуть на производителя Kafka ›0.8.2, чтобы увидеть, подходит ли его парадигма. Необходимость (а не возможность) обрабатывать пакетную обработку самостоятельно привела к нескольким разочаровывающим комментариям в моем коде. - person cacsar; 26.11.2014