Re: Re: Asynchronous Completion Token

If what you are saying is true, how would you handle
3000 connections like this:

3000 connections --> stage 1 --> stage 2

Stage 1: accepts connections and delegate its
processing to stage 2
Stage 2: this stage can`t swallow the produced
channels so will you make a bloquing enqueue here? I
did it ... my result was a BrokenPipeException because
network queue got full.
Perhaps I implemented it wrongly.
When I did, you were right, the stage 2 stopped to
create threads and it was pretty stable.
But the first stage was doomed.

Once I implemented the ACT stuff, the system worked
pretty nice (of course it needed some tuning).
But, as I just seem to be too dumb here... I`m going
to re-read my real-time books again. :D

(Sorry for the joke, dude, I could not resist).
Now, a serious statement: I really tried what you said
and it didn`t work. Perhaps the situation I was to
resolve was a special one and this approach would be a
exception to most of cases so far.
Anyway, I got your approach. It seems reasonable to
try it for the most of cases. 
Again, I`m willing to help (it really doesn`t matter
if my idea was dumb and I was lucky because it worked
somehow[in that special case, because I haven`t tried
other cases on which it would fit]).

Best regards,








 --- Quartz <[email protected]> escreveu: 
> > 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.
> 
> So?
> You need to re-read your books on real-time systems.
> Rule #1: Overall, consumers must be faster than
> producers.
> 
> 
> > 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. 
> 
> First, blocking does not cost anything (beside 2
> context switch).
> The non-blocking argument is only to avoid too many
> threads and lacking scalability.
> As long as no more threads are allocated upon
> backpressure instead of 
> the TM mistakenly thinking the stage is choking, you
> will be fine.
> 
> 
> 
> 		
> __________________________________ 
> 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
>  


	
	
		
_______________________________________________________ 
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.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/