Re: 5.5.27 candidate binaries
Unfortunately, its broken when you run with security enabled. I worked with Mark Thomas on this on 5.5.26, and he sent me a patch to JULI. It looks like it didn't make it in. This issue causes a start up error for every context, plus for me, it breaks my app. Here's a URL to the patch Mark provided me with: http://www.mhsoftware.com/~gsexton/juli_patch.diff Here is the stack trace: [ERROR] [iCalImporter] - Servlet.service() for servlet iCalImporter threw exception java.security.AccessControlException: access denied (java.io.FilePermission /home/gsexton/ROOT/WEB-INF/classes/logging.properties read)java.security.AccessControlException: access denied (java.io.FilePermission /home/gsexton/ROOT/WEB-INF/classes/logging.properties read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.File.exists(File.java:731) at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:828) at org.apache.naming.resources.FileDirContext.lookup(FileDirContext.java:211) at org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:294) at org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:1948) at org.apache.catalina.loader.WebappClassLoader.findResource(WebappClassLoader.java:960) at org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLogManager.java:298) at org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:273) at java.security.AccessController.doPrivileged(Native Method) at org.apache.juli.ClassLoaderLogManager.getClassLoaderInfo(ClassLoaderLogManager.java:270) at org.apache.juli.ClassLoaderLogManager.getLogger(ClassLoaderLogManager.java:175) at java.util.logging.Logger.getLogger(Logger.java:275) at sun.net.www.protocol.http.HttpURLConnection.clinit(HttpURLConnection.java:63) at sun.net.www.protocol.http.Handler.openConnection(Handler.java:44) at sun.net.www.protocol.http.Handler.openConnection(Handler.java:39) at java.net.URL.openConnection(URL.java:945) at com.mhsoftware.cdaily.servlet.iCalImporter.doPost(iCalImporter.java:231) at javax.servlet.http.HttpServlet.service(HttpServlet.java:647) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:262) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:52) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:171) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:167) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:548) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:619) Filip Hanik - Dev Lists wrote: http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.27/ Unless I hear some complaints, I will be posting a vote on Monday Filip
Re: 5.5.27 candidate binaries
George Sexton wrote: Unfortunately, its broken when you run with security enabled. I worked with Mark Thomas on this on 5.5.26, and he sent me a patch to JULI. It looks like it didn't make it in. This issue causes a start up error for every context, plus for me, it breaks my app. That patch is still in the status file, waiting for me to improve it. I'll look at it over the weekend. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.27 blocker: URIEncoding UTF-8 broken for 5.5.trunk
On Mon, 2008-08-25 at 17:16 +0200, Rainer Jung wrote: If we revert the backport of http://svn.eu.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java?r1=642819r2=647307diff_format=h then the redirect loop is gone, and the usual content gets served, but we know, that this change was needed to fix the remaining garbage part of 44494. So reverting it without any alternative is not really an option. Most likely, some backport is missing (many patches made up this input fixes). OTOH, I don't think this particular problem is that critical, so I would be in favor of dropping it if fixing the issue is complex. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.27 blocker: URIEncoding UTF-8 broken for 5.5.trunk
Remy Maucherat schrieb: On Mon, 2008-08-25 at 17:16 +0200, Rainer Jung wrote: If we revert the backport of http://svn.eu.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java?r1=642819r2=647307diff_format=h then the redirect loop is gone, and the usual content gets served, but we know, that this change was needed to fix the remaining garbage part of 44494. So reverting it without any alternative is not really an option. Most likely, some backport is missing (many patches made up this input fixes). OTOH, I don't think this particular problem is that critical, so I would be in favor of dropping it if fixing the issue is complex. Got some more info: 1) What happens inside the new ReadConvertor.recycle(): actually if I print out, which superfluous bytes are eaten by the read() loop inside ReadConvertor.recycle(), I can see, that it's all the bytes making up the PATH in the URL. If I request http://myserver:8080/, recycle read one character, namely /, if I request http://myserver:8080/index.jsp, then recycle reads all characters from /index.jsp. In my understanding of those patches, the time recycle in ReadConvertor gets called, those should have alrady been read and only body bytes left over after request processing should be eaten. 2) So I checked, when recycle() gets called, and I see, that during the first few (here: 2) requests it doesn't get called at all (and those work), and during the following broken requests, it gets called in the following stack: at org.apache.tomcat.util.buf.ReadConvertor.recycle(B2CConverter.java:222) at org.apache.tomcat.util.buf.B2CConverter.recycle(B2CConverter.java:64) at org.apache.catalina.connector.CoyoteAdapter.convertURI(CoyoteAdapter.java:475) at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:265) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:172) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:595) Didn't yet go further into it, but maybe something is wrong in CoyoteAdapter.convertURI? Regards, Rainer P.S: I'll soon need to stop investigating this for today. If anyone can take over that will be nice, because we really should have a working 5.5.27 soon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.27 blocker: URIEncoding UTF-8 broken for 5.5.trunk
Thanks Rainer, I will take a look at it tonight Filip Rainer Jung wrote: Remy Maucherat schrieb: On Mon, 2008-08-25 at 17:16 +0200, Rainer Jung wrote: If we revert the backport of http://svn.eu.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java?r1=642819r2=647307diff_format=h then the redirect loop is gone, and the usual content gets served, but we know, that this change was needed to fix the remaining garbage part of 44494. So reverting it without any alternative is not really an option. Most likely, some backport is missing (many patches made up this input fixes). OTOH, I don't think this particular problem is that critical, so I would be in favor of dropping it if fixing the issue is complex. Got some more info: 1) What happens inside the new ReadConvertor.recycle(): actually if I print out, which superfluous bytes are eaten by the read() loop inside ReadConvertor.recycle(), I can see, that it's all the bytes making up the PATH in the URL. If I request http://myserver:8080/, recycle read one character, namely /, if I request http://myserver:8080/index.jsp, then recycle reads all characters from /index.jsp. In my understanding of those patches, the time recycle in ReadConvertor gets called, those should have alrady been read and only body bytes left over after request processing should be eaten. 2) So I checked, when recycle() gets called, and I see, that during the first few (here: 2) requests it doesn't get called at all (and those work), and during the following broken requests, it gets called in the following stack: at org.apache.tomcat.util.buf.ReadConvertor.recycle(B2CConverter.java:222) at org.apache.tomcat.util.buf.B2CConverter.recycle(B2CConverter.java:64) at org.apache.catalina.connector.CoyoteAdapter.convertURI(CoyoteAdapter.java:475) at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:265) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:172) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:595) Didn't yet go further into it, but maybe something is wrong in CoyoteAdapter.convertURI? Regards, Rainer P.S: I'll soon need to stop investigating this for today. If anyone can take over that will be nice, because we really should have a working 5.5.27 soon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.27 blocker: URIEncoding UTF-8 broken for 5.5.trunk
Filip Hanik - Dev Lists schrieb: Thanks Rainer, I will take a look at it tonight Thank you! Last info chunk for today: in CoyoteAdapter.convertURI, before the try/catch block that either creates or recycles the B2CConverter, the ByteChunk bc coming from the decodedURI contains the correct URI. After the recycle of the B2CConverter, the ByteChunk is empty and thus we end up in a default redirect. Although we already read the correct URI from the request, the B2CConverter associated with the request detroys the already read URI in the recycle. I don't see the delta to 6.0. CoyoteAdapter seems fine, maybe in ByteChunk? Regards, Rainer Filip Rainer Jung wrote: Remy Maucherat schrieb: On Mon, 2008-08-25 at 17:16 +0200, Rainer Jung wrote: If we revert the backport of http://svn.eu.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java?r1=642819r2=647307diff_format=h then the redirect loop is gone, and the usual content gets served, but we know, that this change was needed to fix the remaining garbage part of 44494. So reverting it without any alternative is not really an option. Most likely, some backport is missing (many patches made up this input fixes). OTOH, I don't think this particular problem is that critical, so I would be in favor of dropping it if fixing the issue is complex. Got some more info: 1) What happens inside the new ReadConvertor.recycle(): actually if I print out, which superfluous bytes are eaten by the read() loop inside ReadConvertor.recycle(), I can see, that it's all the bytes making up the PATH in the URL. If I request http://myserver:8080/, recycle read one character, namely /, if I request http://myserver:8080/index.jsp, then recycle reads all characters from /index.jsp. In my understanding of those patches, the time recycle in ReadConvertor gets called, those should have alrady been read and only body bytes left over after request processing should be eaten. 2) So I checked, when recycle() gets called, and I see, that during the first few (here: 2) requests it doesn't get called at all (and those work), and during the following broken requests, it gets called in the following stack: at org.apache.tomcat.util.buf.ReadConvertor.recycle(B2CConverter.java:222) at org.apache.tomcat.util.buf.B2CConverter.recycle(B2CConverter.java:64) at org.apache.catalina.connector.CoyoteAdapter.convertURI(CoyoteAdapter.java:475) at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:265) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:172) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:595) Didn't yet go further into it, but maybe something is wrong in CoyoteAdapter.convertURI? Regards, Rainer P.S: I'll soon need to stop investigating this for today. If anyone can take over that will be nice, because we really should have a working 5.5.27 soon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.27 blocker: URIEncoding UTF-8 broken for 5.5.trunk
OK, cancelled my appointment. More info: I backported all functional changes in o.a.tomcat.util.buf from tc6.x to tc5.5 and can't reproduce the problem any more. Those are very few changes. I'll narrow it down some more during the next hour. Stay tuned. Rainer Rainer Jung schrieb: Filip Hanik - Dev Lists schrieb: Thanks Rainer, I will take a look at it tonight Thank you! Last info chunk for today: in CoyoteAdapter.convertURI, before the try/catch block that either creates or recycles the B2CConverter, the ByteChunk bc coming from the decodedURI contains the correct URI. After the recycle of the B2CConverter, the ByteChunk is empty and thus we end up in a default redirect. Although we already read the correct URI from the request, the B2CConverter associated with the request detroys the already read URI in the recycle. I don't see the delta to 6.0. CoyoteAdapter seems fine, maybe in ByteChunk? Regards, Rainer Filip Rainer Jung wrote: Remy Maucherat schrieb: On Mon, 2008-08-25 at 17:16 +0200, Rainer Jung wrote: If we revert the backport of http://svn.eu.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java?r1=642819r2=647307diff_format=h then the redirect loop is gone, and the usual content gets served, but we know, that this change was needed to fix the remaining garbage part of 44494. So reverting it without any alternative is not really an option. Most likely, some backport is missing (many patches made up this input fixes). OTOH, I don't think this particular problem is that critical, so I would be in favor of dropping it if fixing the issue is complex. Got some more info: 1) What happens inside the new ReadConvertor.recycle(): actually if I print out, which superfluous bytes are eaten by the read() loop inside ReadConvertor.recycle(), I can see, that it's all the bytes making up the PATH in the URL. If I request http://myserver:8080/, recycle read one character, namely /, if I request http://myserver:8080/index.jsp, then recycle reads all characters from /index.jsp. In my understanding of those patches, the time recycle in ReadConvertor gets called, those should have alrady been read and only body bytes left over after request processing should be eaten. 2) So I checked, when recycle() gets called, and I see, that during the first few (here: 2) requests it doesn't get called at all (and those work), and during the following broken requests, it gets called in the following stack: at org.apache.tomcat.util.buf.ReadConvertor.recycle(B2CConverter.java:222) at org.apache.tomcat.util.buf.B2CConverter.recycle(B2CConverter.java:64) at org.apache.catalina.connector.CoyoteAdapter.convertURI(CoyoteAdapter.java:475) at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:265) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:172) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:595) Didn't yet go further into it, but maybe something is wrong in CoyoteAdapter.convertURI? Regards, Rainer P.S: I'll soon need to stop investigating this for today. If anyone can take over that will be nice, because we really should have a working 5.5.27 soon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.27 blocker: URIEncoding UTF-8 broken for 5.5.trunk
It's the available() methde of the class IntermediateInputStream contained in B2CConverter. It doesn't exist in 6.0. If I comment it out in 5.5 trunk. the problem is gone. The method was first introduced in http://svn.apache.org/viewvc/tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/B2CConverter.java?r1=481614r2=568699pathrev=568699diff_format=h and the changed to it's final contents in http://svn.apache.org/viewvc/tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/B2CConverter.java?r1=568699r2=569970diff_format=h I didn't yet check, what negative consequences removing of the method has, or if there is a better implementation for it. We should carefully check the consequences of changing it w.r.t. BZ 44494 with the test webapp, we got for that BZ. Regards, Rainer Rainer Jung schrieb: OK, cancelled my appointment. More info: I backported all functional changes in o.a.tomcat.util.buf from tc6.x to tc5.5 and can't reproduce the problem any more. Those are very few changes. I'll narrow it down some more during the next hour. Stay tuned. Rainer Rainer Jung schrieb: Filip Hanik - Dev Lists schrieb: Thanks Rainer, I will take a look at it tonight Thank you! Last info chunk for today: in CoyoteAdapter.convertURI, before the try/catch block that either creates or recycles the B2CConverter, the ByteChunk bc coming from the decodedURI contains the correct URI. After the recycle of the B2CConverter, the ByteChunk is empty and thus we end up in a default redirect. Although we already read the correct URI from the request, the B2CConverter associated with the request detroys the already read URI in the recycle. I don't see the delta to 6.0. CoyoteAdapter seems fine, maybe in ByteChunk? Regards, Rainer Filip Rainer Jung wrote: Remy Maucherat schrieb: On Mon, 2008-08-25 at 17:16 +0200, Rainer Jung wrote: If we revert the backport of http://svn.eu.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java?r1=642819r2=647307diff_format=h then the redirect loop is gone, and the usual content gets served, but we know, that this change was needed to fix the remaining garbage part of 44494. So reverting it without any alternative is not really an option. Most likely, some backport is missing (many patches made up this input fixes). OTOH, I don't think this particular problem is that critical, so I would be in favor of dropping it if fixing the issue is complex. Got some more info: 1) What happens inside the new ReadConvertor.recycle(): actually if I print out, which superfluous bytes are eaten by the read() loop inside ReadConvertor.recycle(), I can see, that it's all the bytes making up the PATH in the URL. If I request http://myserver:8080/, recycle read one character, namely /, if I request http://myserver:8080/index.jsp, then recycle reads all characters from /index.jsp. In my understanding of those patches, the time recycle in ReadConvertor gets called, those should have alrady been read and only body bytes left over after request processing should be eaten. 2) So I checked, when recycle() gets called, and I see, that during the first few (here: 2) requests it doesn't get called at all (and those work), and during the following broken requests, it gets called in the following stack: at org.apache.tomcat.util.buf.ReadConvertor.recycle(B2CConverter.java:222) at org.apache.tomcat.util.buf.B2CConverter.recycle(B2CConverter.java:64) at org.apache.catalina.connector.CoyoteAdapter.convertURI(CoyoteAdapter.java:475) at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:265) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:172) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:875) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:595) Didn't yet go further into it, but maybe something is wrong in CoyoteAdapter.convertURI? Regards, Rainer P.S: I'll soon need to stop investigating this for today. If anyone can take over that will be nice, because we really should have a working 5.5.27 soon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.27 blocker: URIEncoding UTF-8 broken for 5.5.trunk
I need a small correction: when I delete the available method of the IntermediateInputStream, I can neither reproduce the redirect problem, nor bz44494. My test against bz44494 was wrong. Nevertheless I would strongly prefer the removal of conv.recycle in convertURI in the Adapter code, because I think I understand much better, that we don't need this, than I understand the exact need for the available() method. BTW: The conv.recycle in convertURI is there since the method convertURI was created. At that time recycle was an empty method though. I think we now gave it a meaning, which is not right for both use cases of B2CConverter. I didn't test it, but I expect TC 4.1 trunk to be broken in the same way. Concerning tc6.0 and trunk: we should remove conv.recycle() from convertURI there as well and whoever knows, why we have the available() method should comment, if we need to introduce it to 6.0 and trunk too. Regards, Rainer Rainer Jung schrieb: Unfortunately removing the available() method agains gives us back 44494. But there is some hope. B2CConverter gets used for two different things: 1) It is associated with a request and used inside the adapter to decode the URI. In this case, it seems that during the lifetime of the ByteChunk underlying the B2CConverter (the URI ByteChunk) we only call conv.convert() once. So there is no real need for any conv.recycle() before conv.convert() (cleaning up some unrelated old ByteChunk; if we would need to do that, then we should do it at the end of convertURI for some request and not near the beginning of convertURI for some later request). 2) It is associated with the InputBuffer to transform input data. In this case we mightcall convert() multiple times and handle a difficult relationship between direct access to the Chunks and via convert. Here we need to clean up the ByteChunk at the end of the request handling. As far as I can see, the instances of B2CConverter used for 1) and for 2) are independant of each other. B2CConvertor.recycle() has only one action, it calls ReadConvertor.recycle(), which reads the remaining bytes in the ByteChunk() and throws them away. This seems to be good for 2) (e.g. BZ 44494), but it eats data from a ByteChunk instance associated with the B2CConverter during an earlier request in case 1). I would suggest to simply remove the conv.recycle in case 1). I dn't see any use of it. If we really think we need to eat up remaining bytes in the ByteChunk in 1), then we should do the conv.recycle() near the end of convertURI. Regards, Rainer Rainer Jung schrieb: It's the available() methde of the class IntermediateInputStream contained in B2CConverter. It doesn't exist in 6.0. If I comment it out in 5.5 trunk. the problem is gone. The method was first introduced in http://svn.apache.org/viewvc/tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/B2CConverter.java?r1=481614r2=568699pathrev=568699diff_format=h and the changed to it's final contents in http://svn.apache.org/viewvc/tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/B2CConverter.java?r1=568699r2=569970diff_format=h I didn't yet check, what negative consequences removing of the method has, or if there is a better implementation for it. We should carefully check the consequences of changing it w.r.t. BZ 44494 with the test webapp, we got for that BZ. Regards, Rainer Rainer Jung schrieb: OK, cancelled my appointment. More info: I backported all functional changes in o.a.tomcat.util.buf from tc6.x to tc5.5 and can't reproduce the problem any more. Those are very few changes. I'll narrow it down some more during the next hour. Stay tuned. Rainer Rainer Jung schrieb: Filip Hanik - Dev Lists schrieb: Thanks Rainer, I will take a look at it tonight Thank you! Last info chunk for today: in CoyoteAdapter.convertURI, before the try/catch block that either creates or recycles the B2CConverter, the ByteChunk bc coming from the decodedURI contains the correct URI. After the recycle of the B2CConverter, the ByteChunk is empty and thus we end up in a default redirect. Although we already read the correct URI from the request, the B2CConverter associated with the request detroys the already read URI in the recycle. I don't see the delta to 6.0. CoyoteAdapter seems fine, maybe in ByteChunk? Regards, Rainer Filip Rainer Jung wrote: Remy Maucherat schrieb: On Mon, 2008-08-25 at 17:16 +0200, Rainer Jung wrote: If we revert the backport of http://svn.eu.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java?r1=642819r2=647307diff_format=h then the redirect loop is gone, and the usual content gets served, but we know, that this change was needed to fix the remaining garbage part of 44494. So reverting it without any alternative is not really an option. Most likely, some backport is missing (many patches made up this
Re: 5.5.27
Filip Hanik - Dev Lists wrote: there is a required patch in STATUS.txt before I can actually move this, right now its failing TCK tests Filip Filip Hanik - Dev Lists wrote: How about cutting a release candidate on Monday, Aug 18th and if all is well, have a release towards end of next week? Don't we have the same erreur in trunk and tc6.0.x? Cheers Jean-Frederic Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.27
Filip Hanik - Dev Lists wrote: there is a required patch in STATUS.txt before I can actually move this, right now its failing TCK tests I added a third +1 and some other votes. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.27
there is a required patch in STATUS.txt before I can actually move this, right now its failing TCK tests Filip Filip Hanik - Dev Lists wrote: How about cutting a release candidate on Monday, Aug 18th and if all is well, have a release towards end of next week? Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.27
I will tag afternoon (PST) tomorrow, this gives me a chance to run through the TCK tests first Filip Filip Hanik - Dev Lists wrote: How about cutting a release candidate on Monday, Aug 18th and if all is well, have a release towards end of next week? Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.27
Filip Hanik - Dev Lists schrieb: How about cutting a release candidate on Monday, Aug 18th and if all is well, have a release towards end of next week? +1 Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.27
Filip Hanik - Dev Lists wrote: How about cutting a release candidate on Monday, Aug 18th and if all is well, have a release towards end of next week? +1 I will try and do a 4.1.38 as well. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.27
On Wed, Aug 13, 2008 at 9:33 PM, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: How about cutting a release candidate on Monday, Aug 18th and if all is well, have a release towards end of next week? I'm not a committer, but +1. I'll help test once the RC is bundled. I have been having problems building from source. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.27
On Thu, Aug 14, 2008 at 12:33 AM, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: How about cutting a release candidate on Monday, Aug 18th and if all is well, have a release towards end of next week? +1. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
