JDK-6653412 : Need blocking version of peek() in BlockingQueue implementations
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 5.0
  • Priority: P5
  • Status: Closed
  • Resolution: Not an Issue
  • OS: linux
  • CPU: x86
  • Submitted: 2008-01-22
  • Updated: 2011-02-16
  • Resolved: 2008-03-07
Description
A DESCRIPTION OF THE REQUEST :
There is no blocking version of peek() in BlockingQueue, which means it is impossible to poll the head of the queue efficiently without retrieving the head item (via poll() or take()).

JUSTIFICATION :
A blocking version of peek() is required in order to allow implementations of BlockingQueue which provide queue persistence or guaranteed delivery.  For the latter, a two-stage peek()/take() process is required to ensure that the consumer has completely processed the object before it is removed from the queue.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
public interface BlockingQueue<E> {
...
public E peek(boolean blockIfEmpty);
public E peek(boolean blockIfEmpty, long timeout, TimeUnit unit);
...
}

CUSTOMER SUBMITTED WORKAROUND :
A possible solution is to change the locking structures in LinkedBlockingQueue and its counterparts to be protected rather than private, to allow subclasses to implement this functionality.

Comments
EVALUATION In accordance with the above evaluation, I am closing this as Not a Defect. If a compelling use case is available, we may reconsider and reopen this RFE.
07-03-2008

EVALUATION I'd like to see some more motivation via a use case. If the consumer needs to do some processing after peek() and before take(), how is it guaranteed that the element in question is still at the head of the queue? Perhaps providing the requested API would be a mistake, because it would encourage writing of programs with race conditions? Technically, adding the suggested method implementations seems relatively easy, but the BlockingQueue interface can never be changed, and the proposed methods don't seem worth the confusion of adding some new BlockingQueueEx interface.
23-01-2008