users@grizzly.java.net

AW: AW: Multiple concurrent sendings vanish

From: Lohmann Kevin <kevin.lohmann_at_d-velop.de>
Date: Wed, 2 Dec 2009 11:15:43 +0100

Alexey,
thanks again for the explanation!

That makes everything clear for me.

Grizzly is now going nicely!

By time, I'm trying to switch to 2.0

Cheers,
 Kevin

> -----Ursprüngliche Nachricht-----
> Von: Oleksiy.Stashok_at_Sun.COM [mailto:Oleksiy.Stashok_at_Sun.COM]
> Gesendet: Mittwoch, 2. Dezember 2009 11:10
> An: users_at_grizzly.dev.java.net
> Betreff: Re: AW: Multiple concurrent sendings vanish
>
> Hi Kevin,
>
> >> If connection is being processed by a FilterChain (ProtocolParser
> >> etc), it shouldn't get timed out.
> > that is, what I exactly do (if you mean with FilterChain
> > ProtocolChain)!
> >
> > So my problem with closing connections should not appear?
> Right.
>
> > Sorry, now I'm really confused ;)
> Probably my explanations were not clear.
> Connection might be closed by timeout: when connection is idle longer
> than idle-timeout (no requests come), or connection request is waiting
> for a free worker thread longer than idle-timeout. Once we've got a
> worker thread to process the request - connection will *not* be timed
> out during worker thread processing.
>
> Having said that, want to mention, that we have different timeout
> setting for worker-thread processing, called transaction timeout,
> which will not let worker-thread to hang forever. But it's different
> story.
>
> Hope this will help.
>
> WBR,
> Alexey.
>
> >
> > Cheers,
> > Kevin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> > For additional commands, e-mail: users-help_at_grizzly.dev.java.net
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net