What would be a real world usage of DelayQueue, what common problem it was designed to solve?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.
I recently used a delay queue for rate limiting.
For a limit of X events per second, place each event into a delay queue with a 1 second delay.
If there are X events on the delayQueue, take() from the queue (which blocks until at least 1 expires). That way you allow a short term burst, without exceeding any long-term limits.
This class is perfect for a thread that wants to process multiple delayed events their proper order.
Suppose, for example, you have a display with 100 flashing lights, and all the lights flash at different unrelated rates. You could have a thread for each light, or you could have one thread coordinate all of them using this class. It would work something like this:
DelayQueue takes care of getting the next event to process.
Two real-world examples I can think of:
the main usage would be task timers like the for Timer classes
if one could make the delay independant from the system clock (which I beleive you can, not sure though) you can use it for game events like "after 5 ticks move to X" (otherwise clock jitter wold make this unreliable)
Note that the delays are associated with the elements that go on the queue rather than the queue itself. Some objects that go into the queue could have a delay of zero, whilst some can have a much longer delay:
With this in mind, I can think of a few use cases - though they would probably be fragile and a bit of a code smell with regards to your messaging flow. I'd use alternatives to all of them except in specific situations:
1) Control flow - we know that an order takes 60 seconds to process, so don't read the next order off of the queue until the object has been there for at least 60 seconds.
2) Message flow - A highly asynchronous system where we send off requests to 2 or 3 external services and then release the next task to process the order N seconds later once we know the first batch of jobs will at least have had a chance of completing.
3) Message batching - maybe orders of a certain type are bursty, so lets not process orders received in the last N seconds so we can see if similar orders come in shortly after that can be processed as a batch on the next run.
4) Message priorities - different messages or different customers could get a slightly higher quality of service with a lower or zero delay.
In some cases, objects that you place on a queue should be on that queue for a certain amount of time before they are ready to be dequeued. This is where you use the java.util.concurrent.DelayQueue class, which implements the BlockingQueue interface. The DelayQueue requires that queue objects be resident on the queue for a specified amount of time.
For real world usage example see Minding the Queue article at devx site
protected by gnat Mar 21 '14 at 15:40
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?