Ok, I checked in a fix.

Let me know if it helps.

Costin

On 7 Jun 2002, Jean-Francois Nadeau wrote:

> 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]>
> 
> 


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to