Sa;ut,
glassfish_at_javadesktop.org wrote:
> Hi,
>
>
>> How do you measure it?
>
> 2. MySQL has option for logging long running sql
> 3. See it in MySQL administrator tool
> 4. Just timestamp compare in controller servlet
>
>
>> Do you think you can come with a test case
>
> It occurs on production server, so think it would be neccessary to build test case, which sends also much request.
> Think i am not familiar enough with that things.
>
>
>> Your issue is strange
>
> Yes i know - really strange.
> Perhaps you could exclude glassfish or something depending to jstack.
> Would be nice, if you can view the attached file.
> i dont understand the messages:)
This is showing exactly what I was having in mind, and a very different
problem than the database locking issue:
> "httpSSLWorkerThread-80-73" daemon prio=10 tid=0x00002aaae97fb000 nid=0x84e runnable [0x000000004aed5000..0x000000004aed6b80]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:184)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
> - locked <0x00002aaac0ddeda8> (a sun.nio.ch.Util$1)
> - locked <0x00002aaac0dded90> (a java.util.Collections$UnmodifiableSet)
> - locked <0x00002aaac0ddea00> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
> at com.sun.enterprise.web.connector.grizzly.ByteBufferInputStream.doRead(ByteBufferInputStream.java:259)
> at com.sun.enterprise.web.connector.grizzly.ByteBufferInputStream.read(ByteBufferInputStream.java:167)
> at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:743)
> at org.apache.coyote.http11.InternalInputBuffer$InputStreamInputBuffer.doRead(InternalInputBuffer.java:772)
> at org.apache.coyote.http11.filters.IdentityInputFilter.doRead(IdentityInputFilter.java:139)
> at org.apache.coyote.http11.InternalInputBuffer.doRead(InternalInputBuffer.java:702)
> at org.apache.coyote.Request.doRead(Request.java:465)
> at org.apache.coyote.tomcat5.InputBuffer.realReadBytes(InputBuffer.java:326)
> at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:395)
> at org.apache.coyote.tomcat5.InputBuffer.read(InputBuffer.java:341)
> at org.apache.coyote.tomcat5.CoyoteInputStream.read(CoyoteInputStream.java:247)
> at org.apache.coyote.tomcat5.CoyoteRequest.readPostBody(CoyoteRequest.java:3008)
> at org.apache.coyote.tomcat5.CoyoteRequest.getPostBody(CoyoteRequest.java:2990)
> at com.sun.enterprise.web.connector.coyote.PwcCoyoteRequest.getPostBody(PwcCoyoteRequest.java:356)
> at org.apache.coyote.tomcat5.CoyoteRequest.parseRequestParameters(CoyoteRequest.java:2959)
> at org.apache.coyote.tomcat5.CoyoteRequest.getParameter(CoyoteRequest.java:1281)
> at org.apache.coyote.tomcat5.CoyoteRequestFacade.getParameter(CoyoteRequestFacade.java:392)
> at de.hp.core.internet.CMultiClick.<init>(Unknown Source)
During the parsing of the http message, calling getParameters() seems to
requires more bytes that has been read so far. Hence Grizzly try to read
the missing parameters bytes and waits for the client to push those
bytes. What it means here is the client is not sending the bytes as
expected (as fast as expected). Do you have any proxy in between? Or
does the network get flooded? This doesn't look like a bug in GlassFish,
but really means that all the required bytes are send really slowly from
the client side.
Can you do a test? Can you add the following properties in domain.xml:
-Dcom.sun.enterprise.web.connector.grizzly.readTimeout=1000
and see if the getParameters() performance improve? I suspect you might
get/see IOException as the http parser will not get all the bytes it
require because it will stop waiting for all required bytes. But let's
see :-).
Thanks
-- Jeanfrancois
>
>
> thanx,
> Hammoud
> [Message sent by forum member 'hammoud' (hammoud)]
>
> http://forums.java.net/jive/thread.jspa?messageID=281369
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>