ok, if the stack trace comes from an async thread, then it just means
the CometEvent is closed and has been recycled
Filip
On 08/14/2009 06:01 PM, Jason Ward wrote:
Filip - everything below that is from our (proprietary) classes. I'll
see if I can extract it into a standalone project or at least clean it
to the point where I can distribute. Hope to get that to you on Monday.
As I said tho, the crux of the problem is coming from the first ioex
which doesn't give me a trace... just the error event. But I'm sure
you caught that from my first post..
Filip Hanik - Dev Lists wrote:
don't clip the stack trace please, do you have the full one?
On 08/14/2009 03:24 PM, Jason Ward wrote:
Hello,
I'm seeing IOExceptions when writing/flushing my Comet servlet
OutputStream. The fist exception is difficult to pinpoint, but it
seems it raises and ERROR event which ultimately enacts a
event.close(). This in turn results in the following stack trace for
subsequent operations:
java.lang.NullPointerException
at
org.apache.coyote.http11.InternalNioOutputBuffer.addToBB(InternalNioOutputBuffer.java:620)
at
org.apache.coyote.http11.InternalNioOutputBuffer.commit(InternalNioOutputBuffer.java:611)
at
org.apache.coyote.http11.Http11NioProcessor.action(Http11NioProcessor.java:1033)
at org.apache.coyote.Response.action(Response.java:183)
at org.apache.coyote.Response.sendHeaders(Response.java:379)
at
org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305)
at
org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:288)
at
org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputStream.java:98)
... <clipped>
This is all well and good, but without understanding why the first
IOEx is happening I'm toast.
My research unearthed this old thread
http://mail-archives.apache.org/mod_mbox/tomcat-users/200712.mbox/%3c47741009.7070...@cedrofinances.com.br%3e
("Comet servlet synchronization and flush problems")
I've verified I'm sync'ing on the OutputStream for all write/flush
operations, and I'm calling response.flushBuffer() in the BEGIN
event, I'm not calling event.close() outside of the ERROR / TIMEOUT
/ END event processing and none of them are being called before the
original IOException.
I'm looking for suggestions for other fail-safe practices. Is there
something obvious I'm missing here?
I see from the comet wiki
(http://wiki.apache.org/tomcat/WhatIsComet) that while it's a little
out-dated, it indicates "Inaccurate use of non blocking write API"
could be the cause. However, the isWriteable() API discussed isn't
available. For my testing purposes I put in a forced sleep after
both write() and flush() but I'm still encountering the mysterious
ioexceptions (somewhat sporadically).
I'm ready to accept this idea this is a problem in my code, but the
byte[] I'm pushing down looks valid, I'm sync'ing on the response,
outputstream, write, and even globally on my sendResponse method...
just to be safe. So yeah, I'm running out of ideas.
Any thoughts, suggestions, and advice are greatly appreciated!
Thanks in advance,
JW
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
