users@glassfish.java.net

Re: Grizzly consumes 100% CPU in SelectorThread.doSelect if client disconn

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Tue, 10 Jun 2008 13:04:21 -0400

Salut,

glassfish_at_javadesktop.org wrote:
> Salut,
>
>>>> can you add the following property in domain.xml:
>>>>
>> -Dcom.sun.enterprise.server.ss.ASQuickStartup=false
>>> I did so and restarted the server. The behaviour is
>> the same: Some time after my client disconnects, the
>> java process goes up to nearly 100% CPU usage.
>>> What did you expect? More logging or some different
>> behaviour? What information do you need?
>>
>> No 100% CPU .. that property save my life very often
>> :-) :-)
>
> What is the exact behaviour of this property?

It turns off the following features of GlassFish v2:

http://weblogs.java.net/blog/binod/archive/2005/09/lazy_initializa.html


>
>> OK let's start from scratch. Which platform are you
>> running GlassFish?
>> Any chance you are running on Linux (there is some
>> issues with NIO)
>
> Yes, I am running Kubuntu 7.04 (Feisty)
> with Linux kernel 2.6.20-16-server #2 SMP

Which JDK? I will look at the NIO issue list. Hopefully the issue is
with Grizzly or has been fixed already in the JDK.


>
>> Which version of GlassFish are you using?
>
> V2 ur2
>
>>> How shall I proceed to find out more information?
>> Can you share a little test case? If yes, send it to
>> (jfarcand at apache
>> dot org) and I will take a look
>
> Hmmm, will try to get one. Can I do any logging etc. to see more?
> E.g. which thread is spinning?

It is not simple, but I usually do the following on Solaris:

% prstat -Lp <java PID> (or use [1] on Linux
% pstack PID/LWPID

Then match the result:

> f8800278 ???????? (c497fcb8, c497fe80, a, ec2ff250, f880d120, c497fdb0)

The last line ??????? contains the thread ID: c497fcb8. Then kill -3 PID
and match the thread id. You will know which thread is eating the memory.


>
>>> More details about my application:
>>> =========================
>>> My client keeps the HTTP response stream to a
>> specific servlet open until it stops. This servlet
>> listens to a JMS queue and forwards the messages to
>> the client. If the JMS receive( timeout ) returns
>> without any data, a dummy message is return to the
>> client.
>>
>> In this way, the servlet gets an error writing to
>> the stream if the
>> client closes its end.
>
> Not immediately, but after writing some more bytes. Some buffer fills up.
> Any way to get this faster?

Can you try the current v2 nightly build:

https://glassfish.dev.java.net/downloads/v2.1-b36.html

I suspect you might hit the following issue (just to be sure I'm wrong)

https://glassfish.dev.java.net/issues/show_bug.cgi?id=4987

I might be wrong here, but just to avoid wasting time :-)

>
>> And you are sure your Servlet is not the one that
>> spinning, right?
>
> OK, will check more carefully...

Thanks!!

-- Jeanfrancois

[1] http://www.surrey.lug.org.uk/cgi-bin/wiki.pl?PrstatEquivalent




>
> Many thanks so far, Jörg
> [Message sent by forum member 'jthoennes' (jthoennes)]
>
> http://forums.java.net/jive/thread.jspa?messageID=279470
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>