Re: BlockingQueue and capacity issue

>But what do you do if the blocking_enqueue was *not* allowed by the predicate, say a
>RateLimitingPredicate?  Do you drop the element?  Do you wait and retry after a delay?  Do you
wait >and notify the thread when the rate become lower than the target rate?

In case B, a precidicate only accepts or denies enqueue, invariant to the fact the attempt will be
blocking or not. It has way to know if a simple enqueue or a blocking enqueue was called.

The queue itself should know what to do with the .acccept() result. If non blocking, throws
exception. If blocking, goes to wait(). Unless I've refactored that too, if you don't change a
single line of code, that's the behavior you will get. The whole blocking thing is well past the
predicate.accept test, and in case B, we don't test again.

If you wanna pursue case A, the result is consistant for all I know. If this rate limiting
predicate answered 'no' to .accept(), the blockingenqueue would block, the simple enqueue would
throw some sinkexception subclass (most obviously not SinkFullException to avoid misleading).

RateLimitingPredicate alone disregards the queue size. If you want to add the blocking by size all
the time, then you are effectively cascading predicates. Any predicates that denies enqueue cause
either the exception or the blocking.

Seams complete to me. Isn't it?



		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/