6

Both this:

queueClient.PeekBatch(Convert.ToInt32(60));

And this:

messageReceiver.PeekBatch(Convert.ToInt32(60));

Do not work "completely". They return a smaller amount, And instead I have to "pump" these methods in a loop up to the number of messages I know we have using :

var count = queue.MessageCountDetails.ActiveMessageCount;

What settings I am missing, why is Azure being so stingy and not allowing me to pull back, all 60 messages - I know that are there - at once?

brumScouse
  • 3,166
  • 1
  • 24
  • 38
  • 1
    I feel this is broken, at least it does not behave as the documentation states, nor does it act like a traditional peek. Closet thing I've found is http://stackoverflow.com/a/26195454/102482 but PeekBatch doesn't provide the timespan. If this is actually the case, then the batching aspect is a waste of time if you need to loop using peek/peekbatch anyway. – Finglas Apr 28 '17 at 08:23
  • @BenM I prolly arent using it properly and would loved to be schooled by someone who is a superior S/O'er – brumScouse Apr 28 '17 at 09:36
  • Well I do have more than double the points than you, plus two gold medals, So I think you can take it on good authority that you should probably quit your job today and go and do something a bit better suited to someone of your skill level, may I suggest brick laying? – BenM Apr 28 '17 at 10:17
  • @BenM I think that your points are all gained from quick wins and you are riding on the success of these "easy point getters" (for example: what is an Int in c# type questions) You are like a mini Jon Skeet. – brumScouse Apr 28 '17 at 10:52
  • @BenM Although I feel that brick laying may be a better job for me, I love the challenge of coming in to work and having loads of wtf moments each day, its like being born again each day. I am wide eyed and in awe every day. – brumScouse Apr 28 '17 at 10:53
  • I was looking to see if PeekBatch had an overload with a timeout...with the thinking that it would peek the number of messages it could get WITHIN A DEFAULT TIME....and that's why you get < your specified count. Like if the timeout defaulted to 1 second, you specified 60, you got back 27, 27 was what it could do within that 1 second. But I didn't see it. Anyway, just adding a "what I was guessing" comment. – granadaCoder May 01 '17 at 20:44
  • @brumScouse whilst I agree that some of my points may have been gained from easier questions, look at Finglas' score, he's clearly like one of those camping a-holes you'd get on Unreal Tournament just waiting for people to spawn (or ask question in this case) and then snipe them off for a quick win. Disgusting if you ask me. – BenM May 02 '17 at 12:40
  • @finglas Its not very well documented on msdn or azure docs. Better off looking here https://github.com/Azure-Samples/azure-servicebus-messaging-samples/tree/master/MessageBrowse#using-peekbatch – UK-AL May 03 '17 at 13:44
  • Batching still has a use in speeding up throughput. – UK-AL May 03 '17 at 13:51
  • 1
    @BenM I used to compete semi pro at unreal tournament. And you are indeed right, spawn camping for a easy multi-kill was never off the cards. What is off though, is peekbatch. Thanks for the link to the example UK-AL but the odd behaviour we have seen is different responses (number of messages returned) even though the message payload is the same. Sadly it does appear that a loop until you hit the end or selected message is required. Your link to the sample matches with what we've found. +1 – Finglas May 05 '17 at 12:58

1 Answers1

3

Well according to the azure samples the number you pass in is a upper bound, not an exact match. So you can only rely on it returning that number of messages or fewer.

https://github.com/Azure-Samples/azure-servicebus-messaging-samples/tree/master/MessageBrowse#using-peekbatch

"The count of 20 we pass into PeekBatchAsync for how many messages we'd like to obtain is an upper bound. The service may return any number of messages, up to 20 in this case, but will return at least one message if messages are available past the latest read sequence number"

Batching for azure service bus is normally only used as performance enhancement to avoid the overhead of returning messages one at a time. Internally it may have worked out that returning smaller but more batches is more performant. Batching using exact amounts is not something your program logic should rely upon, I only really use it to improve application performance since allows more throughput over individual peeks.

There also seems to limit in the amount of data returned in one batch which may be applicable to you.

"At most 256 kByte of cumulative message size will be returned in one batch call."

UK-AL
  • 548
  • 4
  • 8
  • I re-read your answer a few times. The fact you have had to pull out anecdotal evidence is a poor withering reflection on M'soft. I equate my expectations to when using substring, BUT I understand this is over the misty stuff in the ether, perhaps this should be documented is my short long answer. – brumScouse May 03 '17 at 14:31
  • And btw, I generally highly regard M'soft and lots of stuff they provide. This is but a small stab at them. – brumScouse May 03 '17 at 14:35
  • @brumScouse Yes, I agree this should be documented better. I've come across this issue before in assuming putting x into peekbatch would return x messages. When really this is just an upper bound. There are few examples like this throughout the documentation. I generally always check the samples now. – UK-AL May 03 '17 at 14:40
  • Seems the samples are better than the MSDN docs in this case. – Finglas May 05 '17 at 13:00