Hi Alexey,
thanks for the explanation, it works now.
But is it up to me to decide, how long the timeout could last? The client sent its request and just because none of the grizzly threads reacts, the request is marked as idle?
Has anyone experiences in setting the timeout up? What is a good timeout in terms of performance etc.?
What about the ReadThreadsCount? Would combining setting this count and timeout be a better solution?
Thanks & cheers,
Kevin
> -----Ursprüngliche Nachricht-----
> Von: Oleksiy.Stashok_at_Sun.COM [mailto:Oleksiy.Stashok_at_Sun.COM]
> Gesendet: Donnerstag, 19. November 2009 18:08
> An: users_at_grizzly.dev.java.net
> Betreff: Re: AW: AW: Multiple concurrent sendings vanish
>
> Hi Kevin,
>
> looks like you don't have any bugs in the code :)
> Grizzly by default kills idle connections after 30 seconds timeout. If
> you're blocking threads for 7.5 seconds, it means that some connection
> requests could not be processed during > 30 seconds, these connection
> are getting closed... that's it.
> To increase idle connection timeout to let's say 60 seconds - you can
> do this:
>
> private void configureServiceDispatcherHandler(
> final int pServiceFileDownloadPort) {
>
> if (this.mSelectorHandler == null) {
>
> this.mSelectorHandler = new TCPSelectorHandler();
>
>
> this.mSelectorHandler.setPort(pServiceFileDownloadPort);
>
> this.mSelectorHandler
> .setProtocolChainInstanceHandler(new
> DefaultProtocolChainInstanceHandler() {
> @Override
> public ProtocolChain poll() {
> return
> Server.this.mPROTOCOL_CHAIN;
> }
> });
> +++ DefaultSelectionKeyHandler keyHandler = new
> DefaultSelectionKeyHandler();
> +++ keyHandler.setTimeout(60000); // 60 seconds
> timeout
> +++
> this.mSelectorHandler.setSelectionKeyHandler(keyHandler);
>
> }
> }
>
> WBR,
> Alexey.
>
>
> On Nov 19, 2009, at 10:23 , Lohmann Kevin wrote:
>
> > Hi,
> >
> > I attached code, that reproduces the problem.
> >
> > Meanwhile I guess, it has something to do with time... In the class
> > 'ServerForwardFilter' in the method 'doSomeThingWithMessage' there
> > is a sleep of 7.5 seconds. If I change these seconds to 5,
> > everything works fine.
> >
> > Also I played with setting the ReadThreadsCount for the controller.
> > Setting the counter high (up to 30), there are many threads (62),
> > but this setting works fine for my problem.
> >
> > I'm pleased to get any remarks.
> >
> > Thanks & cheers,
> > Kevin
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Oleksiy.Stashok_at_Sun.COM [mailto:Oleksiy.Stashok_at_Sun.COM]
> >> Gesendet: Mittwoch, 18. November 2009 17:47
> >> An: users_at_grizzly.dev.java.net
> >> Betreff: Re: AW: Multiple concurrent sendings vanish
> >>
> >> Hi Kevin,
> >>
> >> can you pls. send server and client code, which reproduces the
> issue.
> >>
> >> Thank you.
> >>
> >> WBR,
> >> Alexey.
> >>
> >> On Nov 18, 2009, at 13:42 , Lohmann Kevin wrote:
> >>
> >>> Sorry, one of the attached files was wrong, this one is the right
> >> one.
> >>>
> >>> Cheers,
> >>> Kevin
> >>> <
> >>> MyProtocolParser
> >>> .java
> >>>> ------------------------------------------------------------------
> --
> >> -
> >>> 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
> >
> > <
> > code
> > .zip
> > >--------------------------------------------------------------------
> -
> > 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