Czy pompa komunikatów Azure Service Bus jest rzeczywiście sterowana zdarzeniami?

Question

A więc ostatnio przeglądaliśmy magistralę usług Azure i jesteśmy nieco zdezorientowani, czy powinniśmy używać nieskończonej pętli do odpytywania kolejki/subskrypcji, czy też powinniśmy używać funkcji wywołania zwrotnego/pompy komunikatów OnMessage. Co zmusza do mniejszej liczby operacji, a tym samym kosztuje mniej?

Idealnie chcemy systemu opartego na zdarzeniach, więc nie marnujemy operacji i ogólnie jest to o wiele przyjemniejsze podejście.

Moje pytanie brzmi, czy za pomocą zdarzenia OnMessage zdefiniowanego jako "Przetwarza komunikat w sterowanej zdarzeniem pompie komunikatów" rzeczywiście odbywa się zdarzenie?

Jeśli przyjrzeć się tej stronie (QueueClient.OnMessage): https://msdn.microsoft.com/library/azure/microsoft.servicebus.messaging.queueclient.onmessage.aspx zauważysz uwagę na dole, która stwierdza, że ​​jest to w zasadzie opakowanie wokół nieskończonej pętli, która wywołuje metodę Receive(). To nie brzmi dla mnie bardzo dobrze.

Teraz, jeśli spojrzysz na tę stronę (SubscriptionClient.OnMessage): https://msdn.microsoft.com/en-us/library/azure/dn130336.aspx, ta uwaga nie jest obecna. Czy to samo dotyczy tematów/subskrypcji i kolejek, czy też jest faktycznie sterowane zdarzeniami dla subskrypcji, ale nie dla kolejek?

Dlaczego oni mówią nawet, że jest napędzany przez zdarzenia, kiedy wyraźnie nie jest? Fakt, że uwaga na stronie QueueClient.OnMessage zawiera słowa "nieskończona pętla" i "każda operacja odbierania to zdarzenie rozliczane" jest nieco przerażająca.

Nie martwię się również o to, ile/niewiele to będzie kosztować, jestem bardziej zainteresowany uczynieniem go tak wydajnym, jak to tylko możliwe.

Answer 1

Nie użyłem OnMessage, ale pytanie mnie zainteresowało, więc zrobiłem trochę kopania.

Rozumiem, że podejście OnMessage eliminuje niektóre z typowych problemów związanych z przetwarzaniem komunikatów z kolejki, aby zapewnić bardziej przejrzysty/łatwiejszy sposób na zrobienie tego przy dużo mniejszym zainteresowaniu. Zamiast więc pisać całe rusztowanie wokół pollingu, możesz bardziej skupić się na implementacji "push-like/event driven" (model pompy komunikatów).

A więc masz rację, że w zasadzie wciąż jest to tylko pętla wywołująca Receive() - więc przy domyślnych limitach czasu liczba ankiet byłaby taka sama, a zatem ten sam koszt.

natknąłem tych odnośnikach:

http://fabriccontroller.net/introducing-the-event-driven-message-programming-model-for-the-windows-azure-service-bus/

http://www.flyersoft.net/?p=971 - sprawdź komentarze też, jak to obejmuje to samo pytanie jak twoje.

Więc jest to ta sama tematów/zapisów i kolejek, czy jest to rzeczywiście zdarzeniami subskrypcji, ale nie dla kolejek?

Nie jestem w 100%, ale moim założeniem na podstawie moich badań jest to, że jest to to samo i jest to tylko przypadek, że dokumentacja nie jest jasna.