Hi Kevin
>> 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?)
It closes them.
> although there were bytes sent.
yes, but you can disable this behavior or increase timeout value.
> 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.
If connection is being processed by a FilterChain (ProtocolParser
etc), it shouldn't get timed out.
> Is this a/the suggested way? Fast consuming of incoming bytes and
> delegating these bytes to a worker thread?
Protocol parser code gets called in worker thread, so, by default, you
shouldn't care about any delegation.
Only if you have some long lasting tasks (like SQL requests), it could
make sense to use additional custom thread-pool and process parsed
messages in this thread-pool, to not block worker threads.
WBR,
Alexey.
>> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>