Hi.
I found something very interesting this morning in catalina.out file.
Here it is:
java.lang.IllegalStateException: Current state = FLUSHED, new state =
CODING_END
at
java.nio.charset.CharsetEncoder.throwIllegalStateException(CharsetEncoder.java:933)
at
java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:529)
at
sun.nio.cs.StreamEncoder$CharsetSE.flushLeftoverChar(StreamEncoder.java:356)
at
sun.nio.cs.StreamEncoder$CharsetSE.implClose(StreamEncoder.java:413)
at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:158)
at java.io.OutputStreamWriter.close(OutputStreamWriter.java:222)
at java.io.PrintWriter.close(PrintWriter.java:137)
at
org.apache.catalina.connector.ResponseBase.finishResponse(ResponseBase.java:482)
at
org.apache.catalina.connector.HttpResponseBase.finishResponse(HttpResponseBase.java:236)
at
org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Response.java:190)
at
org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:435)
at
org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:495)
at java.lang.Thread.run(Thread.java:536)
I looked at the AJP13 code (connectors, branch 4.02) in Tomcat CVS and I
found that there is no finally block to close socket connections in case
of failure... Because IllegalStateException is an unchecked exception, I
run out of file descriptors after a short amount of time. Also, because
mod_jk doesn't get the END, Apache deadlocks without my select patch
I use JDK 1.4. It seems to be a NIO bug...
Do you have any idea how to fix that?
Thanks,
jeff
On Fri, 2002-06-07 at 04:30, GOMEZ Henri wrote:
> >The real issue is why tomcat doesn't send the data. Could you try
> >with tomcat4.1 ( or the new coyote-based ajp connector ) ? Is it
> >really a deadlock ( tomcat and mod_jk both waiting for input,
> >i.e. locked in read ) ? Or it is that tomcat for some reasons
> >doesn't send the 'END' message ?
>
> Hum, it recall me some problems which may have been solved in post
> 4.0.3 or in recent jtc (related to thread problem)
>
> >Of course, there is the issue of detecting timeouts - but that's
> >extremely tricky, as some requests may take a long time to process,
> >and waiting 3 seconds ( or any other timeout ) is not a good solution.
> >It is the java side who should send the END message when the
> >requests ends.
>
> Hum, I never liked too much the select, at least on Unix boxes
> a good blocking read make OS wake up your task/thread as soon as
> there is something to do.
>
> >Can you try more debugging, also on the java side ? Maybe the
> >etherreal AJP pluging can help :-)
> >
> >BTW, even if you solved the deadlock you may run into other problems,
> >as requests longer than 3 secs will fail.
>
> Yep, select is not the solution.
>
> You could :
>
> Keep tomcat 4.0.3 and add debugging code
> Use tomcat 4.0.4b2
> Or better switch to tomcat 4.1.3
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
