Hi Jeanfrancois,
thanks for stepping in :)
> Jeanfrancois.Arcand:
> If the client isn't sending anything for 30 seconds, the framework
> close the connection.
But in my case the client sent something, but no grizzly worker thread was ready to consume. So the framework marked those connection as closed (or closed them?) although there were bytes sent.
I just started to refactor my code to make those steps:
1) ProtocolParser parses the incoming bytes to a message
2) Submit this message to a threadpool
I hope, this two steps are so fast, that the framework doesn't get a timeout for a connection.
Is this a/the suggested way? Fast consuming of incoming bytes and delegating these bytes to a worker thread?
> Usually ReadThreadCount == number of core/processor your machine
> supports.
Ah alright, so my setReadThreadCounts(5) doesn't make much sense... ;-)
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
> >
> >
> > ---------------------------------------------------------------------
> > 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