Hi James.
> Indeed that was the issue I was referring to. I also know Grizzly did
> provide a work around quite recently, but as to which GF it made it
> into, that I'm not entirely aware of.
>
> Whilst I'm still based on Linux myself, we decided to temporarily
> delay
> our movement to Grizzly + GF Linux until a JVM patch becomes
> available.
I see.
>
> I've been doing some local tests on 1.0.30-SNAPSHOT and found that it
> didn't seem to manifest itself there. Did you backport that fix?
Yes, we've backported the workaround to 1.0.30-SNAPSHOT.
WBR,
Alexey.
>
> Rgd,
> James
>
> On Wed, 2009-07-15 at 14:37 +0200, Oleksiy Stashok wrote:
>> I think what James means here is JVM "empty Selector spin" issue,
>> when
>> NIO Selector.select() returns immediately even if there is no I/O
>> event ready.
>> This is known issue, and Grizzly has workaround for it, which is
>> integrated to GF. So no need for panic :)
>>
>> James, if you see that workaround doesn't work for you - please let
>> me
>> know.
>>
>> WBR,
>> Alexey.
>>
>> On Jul 15, 2009, at 14:26 , felixx wrote:
>>
>>>
>>> Hi,
>>> I'm having a panic moment here!
>>> How should i read this:
>>> "...Currently on Linux due to and underlying JVM bug, it simply
>>> doesn't work
>>> and it regularly runs into CPU spikes which means that the
>>> application is
>>> unavailable to handle more connections .." !!??
>>> We are planing very soon for a prod deployment, on Linux, of Comet
>>> app
>>> running on GF V3 Preview.
>>> Is this going to work or GF+Grizzly is a 'Windows only' solution?
>>> I hope it's a misunderstanding.
>>> Please comment, thank you.
>>>
>>>
>>>
>>> Cooper, James wrote:
>>>>
>>>> Hi,
>>>> Well I cannot comment on Solaris. But Grizzly performs dramatically
>>>> different on Windows as opposed to Linux, due to differences as to
>>>> how
>>>> the JVM NIO implementation on that platform works. Currently on
>>>> Linux
>>>> due to and underlying JVM bug, it simply doesn't work and it
>>>> regularly
>>>> runs into CPU spikes which means that the application is
>>>> unavailable to
>>>> handle more connections with the system responding with RST
>>>> packets.
>>>> Hopefully there are some Grizzly users with Solaris knowledge that
>>>> can
>>>> clarify how well it works.
>>>>
>>>> Rgds,
>>>> James
>>>>
>>>> On Tue, 2009-07-14 at 23:19 -0700, chandan_evol wrote:
>>>>> Hi All, I am using solaries 10 as the platform. thanks chandan
>>>>> chandan_evol wrote:
>>>>> Hi All, I am using Grizzly 1.9.15 as a HTTP web server for
>>>>> my
>>>>> application. But, whenever the client side sends number of
>>>>> requests (~10 requests in second), the application sends RST
>>>>> packets to the client, after sending FIN to the client side.
>>>>> This seems that the Grizzly server is dropping some requests
>>>>> if it is heavily loaded. Can someone tell me what can
>>>>> prevent
>>>>> the Grizzly server to drop requests. The client is
>>>>> maintaining
>>>>> an HTTP non-persistent connection where everytime connection
>>>>> will be closed if there is a response received for a
>>>>> request.
>>>>> I would appreciate if someone gives me a solution. thanks in
>>>>> advance Chandan
>>>>>
>>>>>
>>>>> ______________________________________________________________________
>>>>> View this message in context: Re: RST/FIN sent from the Grizzly
>>>>> server
>>>>> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context: http://www.nabble.com/RST-FIN-sent-from-the-Grizzly-server-tp24492450p24496837.html
>>> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>