Open tsasioglu opened 6 years ago
It is probably because sbmanager was built with nimbus which uses WindowsAzure.ServiceBus (>= 2.1.3 && <= 2.1.4). So not sure it is going to work if you upgrade that lib.
There should be no reason to require nimbus
On 23 Mar. 2018 9:09 pm, "Drew Freyling" notifications@github.com wrote:
It is probably because sbmanager was built with nimbus which uses WindowsAzure.ServiceBus (>= 2.1.3 && <= 2.1.4). So not sure it is going to work if you upgrade that lib.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GlobalX/SbManager/issues/90#issuecomment-375625772, or mute the thread https://github.com/notifications/unsubscribe-auth/AA71rErFRBdz0hw6L2dN3Grle_ipFc4kks5thNgDgaJpZM4S4e2T .
Sorry you are right, was thinking of another project.
That will be because messages are retrieved from partitioned topics all partitions are queried, the first partition that responds is what then gets returned. doco Hope that helps.
As an aside. I thought using partitioned topics would result in higher availability. But now I'm not convinced as it isn't reflected in the SLA. So I'm starting to move away from them as they seem to complicate things without a proven benefit. EDIT: No proven benefit for my use. Partitioning a topic greatly increases the size limit.
I tried to connect to a partitioned topic and got the error "This client is not supported for a partitioned entity" on peek. I upgraded WindowsAzure.ServiceBus to the latest stable (4.1.0), and I can now peek the (dead letter) queue.
However, I can't see all the messages in the queue (it only shows 3 of 39):
My best guess is that I'm only seeing the messages from a single partition. When I try and requeue one it fails silently. Nothing relevant in the logs.
Any hints how to proceed?
Great tool by the way, thanks.