Make (long) polling of queues configurable

[holtkamp]

Currently most (all?) drivers use a $duration parameter for the popMessage() function which defaults to 5 seconds. For (persistent queues) it would be nice if either:

• this duration can be indicated when invoking deqeue()
• this 'default' is set during driver instantiation and thereby becomes configurable.

Rationale
While the 5 seconds might be great default behaviour, it is not when a large number of queues should be considered for processing any messages on the queue. This might happen when a message queue is used as a CommandBus / EventBus and each Command / Event has its own queue.

This typically results in "a lot" of queues which have low amounts of messages, but still take at least 5 seconds per queue to properly dequeue.

Current idea: https://github.com/holtkamp/bernard/tree/patch-indicate-polling-duration

[ruudk]

I just found out about this issue. I was using a RoundRobinQueue and it was super slow while it didn't process anything. Found out it was related to the $duration = 5 property.

When the queues are empty, it will just continue to the next message. But when there is >=1 message in the queue, it will always block for the default 5 seconds.

@henrikbjorn @acrobat Any idea how to fix this? Should we pass a duration property to the Queue, so that Queue.dequeue can use that?

[holtkamp]

For the PersistentQueue this was covered by #326, not sure what is the deal with the RoundRobinQueue...

[acrobat]

Yes this is definitely something we need to dig in and fix. In a project of mine I've upgraded the lib from an early alpha version to the latest alpha and we had to create an custom legacy driver from one of the first alpha's to overcome queue delays.

One solution could be to make the duration option configurable on a high level or we could if this needs other changes to discard the whole delay thing

[ruudk]

What about this? #339 :)