I'm facing both stuck forever request(never released) and slow request issues
even when I use the default thread pool configuration (min/max - 5/5).
I tested with the scenarios with
1. -Dcom.sun.grizzly.maxSelectorReadThread = 0 : The request processing is
very quick but requests are getting stuck more often.
2. -Dcom.sun.grizzly.maxSelectorReadThread = 1 or 2 : The request
processing is slower but some requests seems to get stuck but they are
released. But STILL some requests are stuck forever.
The chances of getting STUCK are MORE in Powerful server class machines(4
core , 64bit, Linux) than in my laptop(Single core,32 bit , Windows ).
Also abstract from first mail:
One (strange??) thing I have noticed is that if I put a manual delay in
processing (sleep) in as follows I'm not getting this issue.
method DefaultThreadPool.execute(Runnable){
....
if (running){
try {
Thread.sleep(2);
//or Thread.sleep(5);
} catch {....}
workQueue.offer(task);
queueSize.incrementAndGet();
}
}
Thanks,
Abey Tom
BongJaeChang wrote:
>
>> Hi,
>>
>> When I tested it with various situations, I could meet some strange
>> behavior.
>>
>> When I used the read thread count which was not 0, processing request was
>> very slow. For a while, it seemed getting stuck, but it always was
>> released.
>>
>> At first, I thought that the behavior was normal. But when I set the read
>> thread count to be 0, I could know that processing request is very quick.
>>
>> So,
>> 1. Could you please test it again with
>> "-Dcom.sun.grizzly.maxSelectorReadThread=0" ?
>>
>> 2. And is your problem that processing request is slow or the page gets
>> stuck and it is never released?
>>
>> It seems that it is not important the number of the read thread count if
>> it is not 0 because I can always meet the symptom with setting the read
>> thread count to be even 1.
>>
>> And the number of worker threads is not also important because it can see
>> that the number has changed adequately. But it is not sure.
>>
>> So I am also debugging it in order to know why the page is slow when I
>> set the read thread count to be even 1.
>>
>> Thanks.
>>
>> --
>> Bongjae Chang
>
--
View this message in context: http://www.nabble.com/grizzly-comet-webserver-gets-stuck-sometime-while-processing-request-tp24033280p24069466.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.