Salut,
Lohmann Kevin wrote:
> 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?
If the client isn't sending anything for 30 seconds, the framework close
the connection.
>
> Has anyone experiences in setting the timeout up? What is a good timeout in terms of performance etc.?
It really depend on the behavior you want to have, e.g do you wnat to
allow idle connection?
>
> What about the ReadThreadsCount? Would combining setting this count and timeout be a better solution?
Usually ReadThreadCount == number of core/processor your machine supports.
A+
-- jeanfrancois
>
> 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
>