Re: Re: Asynchronous Completion Token

Quartz <[email protected]> Mon, 22 Nov 2004 11:57:25 -0800 (PST)
Newsgroups gmane.comp.java.seda.user
Message-ID <[email protected]>
> With Asynchronous Completion Token (yes, it is more
> like the future thing in java.util.concurrent -
> we'call it ACT) we'll avoid blocking since the thread
> that enqueued the event to be processed will be
> notified sometime in the future when the event is
> processed.

So, what is this thread doing then?
It will either wait() or do more processing, storing incredible amounts of ACT/Future,
relying on uncontrollable jdk timer threads instead of sandtorm threads, and actually not
implementing backpressure at all (which, may I remind you, is the main purpose of a
blocking_enqueue). I'm telling you, this ACT/Future will not work.


> The idea behind this concept is the same of the
> asynchronous IO. We can estabilish much more
> connections coming from sockets than if we're
> blocking.

It isn't the same. With NIO, the queue are from the kernel, and the threads poll selectors. There
isn't a sandstorm queue for such data. The backpressure (if many sockets are ready at same time)
in that case is handled by the kernel (who also manages the memory required for such amount of
connections). I trust kernels to stop making selectors ready (putting data in socket channels) if
they are not read (channels full), effectively kind of 'blocking on enqueue'). Note that a kernel
socket handler will also stop pulling data from network card, and clients effectively will feel
this backpressure.

Here, we are talking about pure java code in a stage that overproduces queue elements in a
downstream sink. It is obvious that when it downstream queues are full, an upstream stage has to
slow down somehow, possibly completely block.


> I guess that the main idea is not to block enqueue
> something but not to block dequeue instead.

I didn't get this.
But anyway, we sure need blocking_dequeue, for idle stages.
And I maintain we need a blocking_enqueue, for backpressure.
I haven't heard a single other technique that could solve the backpressure problem in a scalable
way.




		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 



-------------------------------------------------------
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/