Re: Re: Asynchronous Completion Token

I agree that to solve the main problem of backpressure
the "only" way should be to implement a blocking
enqueue to slow down the first stage (the
overproducing one).

But, in fact, if we can`t slow it down (I mean, we`re
not allowed to slow it because the system must be
responsive)? (That happened to me when I worked for a
telecom).
Everything has to be in real time. Blocking surely
will slow all down and create a network queue (for
example).

We`ll just transfer the chaos from the slow (or less
performing stage) stage to the other stage.

The main idea of what I said is that we can try to
increase overall performance of the system by trying
to avoid everything that blocks. 

Well, I`m just trying to discuss something here, not
imposing that it`ll work.

It`s just an idea.







 --- Quartz <[email protected]> escreveu: 
> > 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/
> _______________________________________________
> SEDA-users mailing list
> [email protected]
>
https://lists.sourceforge.net/lists/listinfo/seda-users
>  

__________________________________________________
Converse com seus amigos em tempo real com o Yahoo! Messenger 
http://br.download.yahoo.com/messenger/ 


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