Does SQL Server Service Broker load balance when External Activator is used? -

say have queue has high load throughout day. each of messages in queue takes several seconds process.

if have 4 machines setup external activator (all configured same queue/service), work?

if work, load balance (spreading work out evenly across worker machines)?

this boils down, ultimately, how multiple pending waitfor (receive) statements serviced. consider have 4 instances of app running, each 'listens' on same queue, issuing waitfor(receive). message becomes available in queue, question is: which of pending waitfor(receive) message?

the answers surprises many, , design: the issued waitfor(receive) message. not oldest one, not random one, newest one. in other words, lifo order listeners.

why? behavior intentional , intent have few listeners needed handle load. have 4 processes listening. 1 gets message, processes , issues again waitfor(receive), starting listen again more messages. next message, when arrives, given, deterministically, same process, because issued waitfor(receive). listener message, process , issue again waitfor(receive). , will, again, deterministically next message. here gist of it: if single listener can handle incoming traffic, other 3 redundant. after while pending waitfor(receive) time out , these processes can safely go away (exit).

a second process may message if arrives (becomes available) while first listener busy processing message (ie had not posted new waitfor(receive)).

so why good? there piece of puzzle: understanding when activation occurs. if lone processing thread can no longer handle incoming traffic, new processing thread (internal or external) spawned, configured max_queue_readers.

so there have it, between these 2 behaviors self-throttled optimal number of readers (processes, threads):

• when traffic spikes , there few reader activation mechanism spawn new processing thread. triggered when 5 seconds pass no processing thread manages 'drain' queue (receive returns empty rowset)
• when traffic slows down , there many listeners activated minimum required handle traffic kept alive, while surplus left time out
• if traffic dries period, threads/processes may go away (0 pending waitfor(receive)). when message arrives processing thread activated process it.

keep in mind due correlated message locking (conversation group locks) queue may have messages in it, none of them available process new thread (ie. they're locked). activation/waitfor purposes situation means queue 'empty' (no messages available new processor).

finally, happen, application has behave correctly:

• activate new thread when notified (internal activation this, external activator correctly)
• the processing threads should issue waitfor(receive) reasonable time out , exit if statement times out (it return empty result set, not error).
• it imperative issue receive when activated. if fail so, queue monitor go notified state , won't activate again. see understanding queue monitors.