[Bug 54684] New: toString() causes NoClassDefFoundError exception
https://issues.apache.org/bugzilla/show_bug.cgi?id=54684 Bug ID: 54684 Summary: toString() causes NoClassDefFoundError exception Product: Tomcat Modules Version: unspecified Hardware: PC Status: NEW Severity: normal Priority: P2 Component: jdbc-pool Assignee: dev@tomcat.apache.org Reporter: lich...@yahoo.com Classification: Unclassified When turning on DEBUG logging, toString() causes the following exception. It happens in an OSGi environment. SLF4J: Failed toString() invocation on an object of type [org.apache.tomcat.jdbc.pool.DataSource] 2013-03-12 14:17:13,612 | DEBUG | Blueprint Extender: 1| ServiceRecipe | lueprint.container.ServiceRecipe 276 | 7 - org.apache.aries.blueprint.core - 1.1.0 | Creating service instance java.lang.NoClassDefFoundError: javax/naming/spi/ObjectFactory at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:791) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2128) at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1432) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at org.apache.tomcat.jdbc.pool.PoolProperties.toString(PoolProperties.java:804) at java.lang.String.valueOf(String.java:2854) at java.lang.StringBuilder.append(StringBuilder.java:128) at org.apache.tomcat.jdbc.pool.DataSourceProxy.toString(DataSourceProxy.java:215) at org.slf4j.helpers.MessageFormatter.safeObjectAppend(MessageFormatter.java:304) at org.slf4j.helpers.MessageFormatter.deeplyAppendParameter(MessageFormatter.java:276) at org.slf4j.helpers.MessageFormatter.arrayFormat(MessageFormatter.java:230) at org.slf4j.helpers.MessageFormatter.format(MessageFormatter.java:124) at org.ops4j.pax.logging.slf4j.Slf4jLogger.debug(Slf4jLogger.java:280) at org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:302) at org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:249) at org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:146) at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88) at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245) at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183) at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668) at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370) at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106) at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.ClassNotFoundException: javax.naming.spi.ObjectFactory not found by org.apache.tomcat.jdbc [165] at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ... 41 more -- You are rec
[Bug 54684] PoolProperties.toString() causes NoClassDefFoundError exception
https://issues.apache.org/bugzilla/show_bug.cgi?id=54684 Martin Lichtin changed: What|Removed |Added Summary|toString() causes |PoolProperties.toString() |NoClassDefFoundError|causes NoClassDefFoundError |exception |exception OS||All -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54599] DataSource password is exposed to applications via toString method
https://issues.apache.org/bugzilla/show_bug.cgi?id=54599 Martin Lichtin changed: What|Removed |Added CC||lich...@yahoo.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54684] PoolProperties.toString() causes NoClassDefFoundError exception
https://issues.apache.org/bugzilla/show_bug.cgi?id=54684 --- Comment #1 from Violeta Georgieva --- The current Import-Package contains Import-Package: javax.management;version="0", javax.management.openmb ean;version="0", javax.naming;version="0", javax.sql;version="0", org .apache.juli.logging;version="[6.0.18, 7.0.0)" We need to add "javax.naming.spi" also to it -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54684] PoolProperties.toString() causes NoClassDefFoundError exception
https://issues.apache.org/bugzilla/show_bug.cgi?id=54684 --- Comment #2 from Violeta Georgieva --- Also this version range is strange because it specifies that jdbc-pool can work only with org.apache.juli.logging version 6.x. Is that correct? org.apache.juli.logging;version="[6.0.18, 7.0.0)" -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
On 03/13/2013 01:20 AM, Mark Thomas wrote: And an infinite loop is entered. I believe I can fix this by changing how I do the buffering in WebSocket so I don't end up having to write short 4 byte chunks. I have been meaning to do this for a while anyway. That said, this does look like an issue with APR/native and SSL. Thoughts? The only solution would be to have some sort of different retvals for real EAGAIN (network layer) and case when encryption cannot be made (protocol layer) due to insufficient data. That is if OpenSSL returns some distinct error in such case. Perhaps the internal buffering would be a way to go, cause we poll only on network events, and if that's satisfied we need a different kind of queue for filling the minimum write buffer. I'll try to dig and see if we can distinguish between those different EAGAIN retvals. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54684] PoolProperties.toString() causes NoClassDefFoundError exception
https://issues.apache.org/bugzilla/show_bug.cgi?id=54684 --- Comment #3 from Martin Lichtin --- (In reply to comment #2) > Also this version range is strange because it specifies that jdbc-pool can > work only with org.apache.juli.logging version 6.x. Is that correct? > > org.apache.juli.logging;version="[6.0.18, 7.0.0)" Yes it seems wrong. See also bug 54684 where this is discussed. Even worse, because Juli is not packaged as an OSGi bundle (and therefore not versioned for an OSGi import), the version range causes yet another issue. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1455854 - /tomcat/trunk/modules/jdbc-pool/resources/MANIFEST.MF
Author: violetagg Date: Wed Mar 13 09:57:37 2013 New Revision: 1455854 URL: http://svn.apache.org/r1455854 Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=54684 Added 'javax.naming.spi' to the header 'Import-Package' Modified: tomcat/trunk/modules/jdbc-pool/resources/MANIFEST.MF Modified: tomcat/trunk/modules/jdbc-pool/resources/MANIFEST.MF URL: http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/resources/MANIFEST.MF?rev=1455854&r1=1455853&r2=1455854&view=diff == --- tomcat/trunk/modules/jdbc-pool/resources/MANIFEST.MF (original) +++ tomcat/trunk/modules/jdbc-pool/resources/MANIFEST.MF Wed Mar 13 09:57:37 2013 @@ -18,5 +18,6 @@ Import-Package: javax.management;version="0", javax.management.openmbean;version="0", javax.naming;version="0", + javax.naming.spi;version="0", javax.sql;version="0", org.apache.juli.logging;version="[6.0.18, 7.0.0)" - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
What's your test platform (or tests platforms) ? Differents OS, kernel configuration, OpenSSL / APR could bring various results 2013/3/13 Mladen Turk > On 03/13/2013 01:20 AM, Mark Thomas wrote: > >> >> And an infinite loop is entered. >> >> I believe I can fix this by changing how I do the buffering in WebSocket >> so I don't end up having to write short 4 byte chunks. I have been >> meaning to do this for a while anyway. >> >> That said, this does look like an issue with APR/native and SSL. >> >> Thoughts? >> >> > The only solution would be to have some sort of different > retvals for real EAGAIN (network layer) and case when encryption > cannot be made (protocol layer) due to insufficient data. > That is if OpenSSL returns some distinct error in such case. > > Perhaps the internal buffering would be a way to go, cause > we poll only on network events, and if that's satisfied we > need a different kind of queue for filling the minimum write > buffer. I'll try to dig and see if we can distinguish between > those different EAGAIN retvals. > > > Regards > -- > ^TM > > > --**--**- > To unsubscribe, e-mail: > dev-unsubscribe@tomcat.apache.**org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Strange APR/native behaviour
Henri Gomez wrote: >What's your test platform (or tests platforms) ? > >Differents OS, kernel configuration, OpenSSL / APR could bring various >results I've seen the same behaviour (either with the test case or with the Autobahn test suite) on the following platforms: Windows Server 2008 R2 with 64 bit 1.1.27 native dll built with APR 1.4.6 and OpenSSL 1.0.1d from dist.a.o Ubuntu 12.04 LTS 64 bit with native lib 1.1.27 built locally with APR 1.4.6 and OpenSSL 1.0.1 running as a virtual machine on the above OS. There is certainly a timing aspect to this that does vary by platform. The problem only happens when the server is writing fast enough for it to fill up the send buffer triggering an EAGAIN from the socket write and even then the error doesn't always occur. Mark > >2013/3/13 Mladen Turk > >> On 03/13/2013 01:20 AM, Mark Thomas wrote: >> >>> >>> And an infinite loop is entered. >>> >>> I believe I can fix this by changing how I do the buffering in >WebSocket >>> so I don't end up having to write short 4 byte chunks. I have been >>> meaning to do this for a while anyway. >>> >>> That said, this does look like an issue with APR/native and SSL. >>> >>> Thoughts? >>> >>> >> The only solution would be to have some sort of different >> retvals for real EAGAIN (network layer) and case when encryption >> cannot be made (protocol layer) due to insufficient data. >> That is if OpenSSL returns some distinct error in such case. >> >> Perhaps the internal buffering would be a way to go, cause >> we poll only on network events, and if that's satisfied we >> need a different kind of queue for filling the minimum write >> buffer. I'll try to dig and see if we can distinguish between >> those different EAGAIN retvals. >> >> >> Regards >> -- >> ^TM >> >> >> >--**--**- >> To unsubscribe, e-mail: >dev-unsubscribe@tomcat.apache.**org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.38
2013/3/8 Mark Thomas wrote: > The proposed Apache Tomcat 7.0.38 release is now available for voting. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.38/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-002/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_38/ > > The proposed 7.0.38 release is: > [ ] Broken - do not release > [ ] Stable - go ahead and release as 7.0.38 Stable > In OSGi environment every application deployment fails with NPE Caused by: java.lang.NullPointerException at org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java:234) at org.eclipse.gemini.web.tomcat.internal.ChainingJarScanner.scan(ChainingJarScanner.java:46) at org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(ContextConfig.java:1918) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1268) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:878) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:369) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) NPE is thrown because there might be no parent loader loader = loader.getParent(); revision 1448831 changes the behaviour Regards Violeta - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
On 03/13/2013 01:29 PM, Mark Thomas wrote: Henri Gomez wrote: What's your test platform (or tests platforms) ? Differents OS, kernel configuration, OpenSSL / APR could bring various results I've seen the same behaviour (either with the test case or with the Autobahn test suite) on the following platforms: Windows Server 2008 R2 with 64 bit 1.1.27 native dll built with APR 1.4.6 and OpenSSL 1.0.1d from dist.a.o Ubuntu 12.04 LTS 64 bit with native lib 1.1.27 built locally with APR 1.4.6 and OpenSSL 1.0.1 running as a virtual machine on the above OS. There is certainly a timing aspect to this that does vary by platform. The problem only happens when the server is writing fast enough for it to fill up the send buffer triggering an EAGAIN from the socket write and even then the error doesn't always occur. I can create a debug version which would write couple of lines to the dbgview.exe window (from SysInternals http://technet.microsoft.com/en-us/sysinternals/bb896647) Fancy to give it a shot. It would be cool to see what are the actual internal results of SSL_write API call Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
On 13/03/2013 13:12, Mladen Turk wrote: > On 03/13/2013 01:29 PM, Mark Thomas wrote: >> Henri Gomez wrote: >> >>> What's your test platform (or tests platforms) ? >>> >>> Differents OS, kernel configuration, OpenSSL / APR could bring various >>> results >> >> I've seen the same behaviour (either with the test case or with the >> Autobahn test suite) on the following platforms: >> >> Windows Server 2008 R2 with 64 bit 1.1.27 native dll built with APR >> 1.4.6 and OpenSSL 1.0.1d from dist.a.o >> >> Ubuntu 12.04 LTS 64 bit with native lib 1.1.27 built locally with APR >> 1.4.6 and OpenSSL 1.0.1 running as a virtual machine on the above OS. >> >> There is certainly a timing aspect to this that does vary by platform. >> The problem only happens when the server is writing fast enough for it >> to fill up the send buffer triggering an EAGAIN from the socket write >> and even then the error doesn't always occur. >> > > I can create a debug version which would write couple of lines to > the dbgview.exe window (from SysInternals > http://technet.microsoft.com/en-us/sysinternals/bb896647) > > Fancy to give it a shot. > It would be cool to see what are the actual internal results of > SSL_write API call Thanks. Setting up to test with that now. Refactoring isn't looking like much fun right now and I am concerned about handling of very short (e.g. 1 byte of data) WebSocket frames over SSL. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
On 13/03/2013 13:36, Mark Thomas wrote: > On 13/03/2013 13:12, Mladen Turk wrote: >> I can create a debug version which would write couple of lines to >> the dbgview.exe window (from SysInternals >> http://technet.microsoft.com/en-us/sysinternals/bb896647) >> >> Fancy to give it a shot. >> It would be cool to see what are the actual internal results of >> SSL_write API call > > Thanks. Setting up to test with that now. http://people.apache.org/~markt/random/2013-03-13-apr-sos-ssl-debug.log Hope this helps find a fix. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
On 03/13/2013 02:47 PM, Mark Thomas wrote: On 13/03/2013 13:36, Mark Thomas wrote: On 13/03/2013 13:12, Mladen Turk wrote: I can create a debug version which would write couple of lines to the dbgview.exe window (from SysInternals http://technet.microsoft.com/en-us/sysinternals/bb896647) Fancy to give it a shot. It would be cool to see what are the actual internal results of SSL_write API call Thanks. Setting up to test with that now. http://people.apache.org/~markt/random/2013-03-13-apr-sos-ssl-debug.log Hope this helps find a fix. 00247.85507011 [3976] SSL_write returned -1, apr_get_netos_error=730035 SSL_get_error=3 Ok, that's a first failure with is WSAEWOULDBLOCK and SSL_get_error=3 is SSL_ERROR_WANT_WRITE 00267.85627747 [3976] SSL_write returned -1, apr_get_netos_error=0 SSL_get_error=1 That's a problem apr_get_netos_error returned zero (and thats what we return) However SSL_get_error returned SSL_ERROR_SSL (1) and we don't handle that! Sending you a version that returns APR_EGENERAL on SLL_ERROR_SSL ... Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54684] PoolProperties.toString() causes NoClassDefFoundError exception
https://issues.apache.org/bugzilla/show_bug.cgi?id=54684 --- Comment #4 from Martin Lichtin --- I ment to refer to bug 52318 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
On 13/03/2013 14:07, Mladen Turk wrote: > On 03/13/2013 02:47 PM, Mark Thomas wrote: >> On 13/03/2013 13:36, Mark Thomas wrote: >>> On 13/03/2013 13:12, Mladen Turk wrote: >> I can create a debug version which would write couple of lines to the dbgview.exe window (from SysInternals http://technet.microsoft.com/en-us/sysinternals/bb896647) Fancy to give it a shot. It would be cool to see what are the actual internal results of SSL_write API call >>> >>> Thanks. Setting up to test with that now. >> >> http://people.apache.org/~markt/random/2013-03-13-apr-sos-ssl-debug.log >> >> Hope this helps find a fix. >> > > 00247.85507011[3976] SSL_write returned -1, > apr_get_netos_error=730035 SSL_get_error=3 > > Ok, that's a first failure with is WSAEWOULDBLOCK and SSL_get_error=3 is > SSL_ERROR_WANT_WRITE > > 00267.85627747[3976] SSL_write returned -1, > apr_get_netos_error=0 SSL_get_error=1 > > That's a problem > apr_get_netos_error returned zero (and thats what we return) > However SSL_get_error returned SSL_ERROR_SSL (1) and we don't handle that! > > Sending you a version that returns APR_EGENERAL on SLL_ERROR_SSL ... Thanks. That fails fast which is good but still fails. Fundamentally we need to be able to handle the situation when we have some, but not enough data for OpenSSL. On a possibly related topic... I've noticed that the non-blocking writes via APR/native doesn't behave as I would expect. Consider the output from the test case [1] The writes at line 3 and 8 suggest (to me at least) that the server hasn't yet written any data as the return value from the Socket.send call is zero. However, clearly data has been written since line 5 tells us that the client has read some data. I am certain this isn't a timing issue with the log messages because I have stepped through this with a debugger. Why doesn't APR/native return the bytes written for Socket.send? Mark [1] http://people.apache.org/~markt/random/2013-03-13-TestSocket-output.txt - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
On 03/13/2013 03:25 PM, Mark Thomas wrote: On 13/03/2013 14:07, Mladen Turk wrote: 00267.85627747[3976] SSL_write returned -1, apr_get_netos_error=0 SSL_get_error=1 That's a problem apr_get_netos_error returned zero (and thats what we return) However SSL_get_error returned SSL_ERROR_SSL (1) and we don't handle that! Sending you a version that returns APR_EGENERAL on SLL_ERROR_SSL ... Thanks. That fails fast which is good but still fails. Fundamentally we need to be able to handle the situation when we have some, but not enough data for OpenSSL. Sure. I just returned APR_EGENERAL. Some dedicated retval would be required so that Java part figures out more data is needed. Are there any error descriptions in dbgview window? On a possibly related topic... I've noticed that the non-blocking writes via APR/native doesn't behave as I would expect. Consider the output from the test case [1] SSL_write is weird. Docs says that if the return value is EAGAIN the next SSL_write *must* be called with the same params. I presume it internally maintains a state logic or something. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1455973 - /tomcat/trunk/modules/jdbc-pool/resources/MANIFEST.MF
Author: violetagg Date: Wed Mar 13 14:50:17 2013 New Revision: 1455973 URL: http://svn.apache.org/r1455973 Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52318 The version for imported package 'org.apache.juli.logging' is extended to include 7.0.x versions. Patch provided by Martin Lichtin. Modified: tomcat/trunk/modules/jdbc-pool/resources/MANIFEST.MF Modified: tomcat/trunk/modules/jdbc-pool/resources/MANIFEST.MF URL: http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/resources/MANIFEST.MF?rev=1455973&r1=1455972&r2=1455973&view=diff == --- tomcat/trunk/modules/jdbc-pool/resources/MANIFEST.MF (original) +++ tomcat/trunk/modules/jdbc-pool/resources/MANIFEST.MF Wed Mar 13 14:50:17 2013 @@ -20,4 +20,4 @@ Import-Package: javax.naming;version="0", javax.naming.spi;version="0", javax.sql;version="0", - org.apache.juli.logging;version="[6.0.18, 7.0.0)" + org.apache.juli.logging;version="[6.0.18, 7.1.0)" - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
On 03/13/2013 03:25 PM, Mark Thomas wrote: On 13/03/2013 14:07, Mladen Turk wrote: Sending you a version that returns APR_EGENERAL on SLL_ERROR_SSL ... Thanks. That fails fast which is good but still fails. Fundamentally we need to be able to handle the situation when we have some, but not enough data for OpenSSL. BTW, looking at some OpenSSL examples, whenever SSL_ERROR_SSL is returned it usually means connection needs to get recycled (closed). Perhaps we should check for a reason SSL_ERROR_SSL is returned cause that doesn't look like a normal thing. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54688] New: the string \\$ in a jsp is escape in resulting page : \$
https://issues.apache.org/bugzilla/show_bug.cgi?id=54688 Bug ID: 54688 Summary: the string \\$ in a jsp is escape in resulting page : \$ Product: Tomcat 7 Version: 7.0.34 Hardware: PC OS: Windows XP Status: NEW Severity: regression Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: guillaume.boni...@actemedia.com Classification: Unclassified To reproduce the BUG create a blank jsp containing : there is two backslash here => \\$ Resulting page show : there is two backslash here => \$ In tomcat 6 the result is correct. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
On 13/03/2013 14:55, Mladen Turk wrote: > On 03/13/2013 03:25 PM, Mark Thomas wrote: >> On 13/03/2013 14:07, Mladen Turk wrote: >>> >>> Sending you a version that returns APR_EGENERAL on SLL_ERROR_SSL ... >> >> Thanks. That fails fast which is good but still fails. Fundamentally we >> need to be able to handle the situation when we have some, but not >> enough data for OpenSSL. >> > > BTW, looking at some OpenSSL examples, whenever SSL_ERROR_SSL is returned > it usually means connection needs to get recycled (closed). > Perhaps we should check for a reason SSL_ERROR_SSL is returned cause that > doesn't look like a normal thing. Thanks for the updated debug dll. Results (from the last good write to when it fails follow). [880] ssl_socket_send 8192 bytes with timeout -1 [880] SSL_write wrote 8192 bytes [880] ssl_socket_send 4 bytes with timeout -1 [880] SSL_write returned -1, apr_get_netos_error=730035 SSL_get_error=3 [880] ssl_socket_send 4 bytes with timeout -1 [880] SSL_write returned -1, apr_get_netos_error=0 SSL_get_error=1 [880] SSL_ERROR_SSL error in queue=336195711 [880] bad write retry - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Trivial Update of "FredMMKU" by FredMMKU
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "FredMMKU" page has been changed by FredMMKU: http://wiki.apache.org/tomcat/FredMMKU New page: Got nothing to say about me at all.<> <> Feel free to visit my weblog [[http://a-market.pl/|częśCi Skoda wrocłAw]] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "LocalBadContent" by ChuckCaldarale
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "LocalBadContent" page has been changed by ChuckCaldarale: http://wiki.apache.org/tomcat/LocalBadContent?action=diff&rev1=79&rev2=80 2look4beds\.com 741\.com 9cy\.com + a-market\.pl accountsandadvice alcor\-holding allfreeads\.com - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54690] New: HTTPS BIO/NIO connector does not enable TLS 1.1 and TLS 1.2 by default
https://issues.apache.org/bugzilla/show_bug.cgi?id=54690 Bug ID: 54690 Summary: HTTPS BIO/NIO connector does not enable TLS 1.1 and TLS 1.2 by default Product: Tomcat 7 Version: 7.0.37 Hardware: PC OS: Windows XP Status: NEW Severity: normal Priority: P2 Component: Connectors Assignee: dev@tomcat.apache.org Reporter: ognjen.d.blagoje...@gmail.com Classification: Unclassified As users already noted [1], default HTTPS BIO/NIO connector in Tomcat 7.0.37 enables only SSLv3 and TLSv1, while Tomcat 6.0.36 enables SSLv3, TLSv1, TLSv1.1 and TLSv1.2. The reason for this change of behavior is that: 1. Tomcat 6, with default HTTPS connector configuration, does not call socket.setEnabledProtocols, thus enabling SSLv3, TLSv1, TLSv1.1 and TLSv1.2, while 2. Tomcat 7, with default HTTPS connector configuration, calls socket.setEnabledProtocols(enabledProtocols), where enabledProtocols is obtained with: context.getDefaultSSLParameters().getProtocols(). This, contrary to not calling setEnabledProtocols at all, results in enabling only SSLv3 and TLSv1. I propose that Tomcat 7 mimics Tomcat 6 behavior, and if attribute sslEnabledProtocols (in HTTPS connector in server.xml) is not set, then method socket.setEnabledProtocols is not invoked. Everything is tested with Oracle JDK 1.7.0_15. More details on post on Tomcat dev list [2]. [1] https://twitter.com/ivanristic/status/303798231920431104 [2] http://www.mail-archive.com/dev@tomcat.apache.org/msg71522.html -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 6 and Tomcat 7 enables different TLS protocols by default
On 8.3.2013 11:14, Ognjen Blagojevic wrote:
Hi,
As previously discussed on user list [1], HTTPS JSSE Connectors (both
BIO and NIO) have different behavior in Tomcat 6 and in Tomcat 7, in
terms of enabled TLS/SSL protocols.
(I repeat the parts from that thread here.)
Tomcat 6 will by default enable SSLv3, TLSv1, TLSv1.1 and TLSv1.2, while
Tomcat 7 will enable SSLv3 and TLSv1. This is counter-intuitive and
might introduce problems when upgrading from Tomcat 6 to Tomcat 7.
Reason for this discrepancy is that in Tomcat 6 code, if (undocumented)
attribute "protocols" is omitted, method socket.setEnabledProtocols is
not being invoked (JSSESocketFactory, lines 700-702, in tc6.0.x/trunk):
protected void setEnabledProtocols(SSLServerSocket socket,
String []protocols){
if (protocols != null) {
socket.setEnabledProtocols(protocols);
}
}
Default on Oracle JDK 7 (1.7.0_15), when socket.setEnabledProtocols is
not invoked is to enable SSLv2Hello (pseudo protocol), SSLv3, TLSv1,
TLSv1.1, TLSv1.2.
In Tomcat 7, when (documented) attribute sslEnabledProtocols is omitted,
method socket.setEnabledProtocols will be invoked with default protocols
enabled (JSSESocketFactory linkes 679-681 and line 727, in tc7.0.x/trunk)
if ((requestedProtocols == null)
|| (requestedProtocols.length == 0)) {
return context.getDefaultSSLParameters().getProtocols();
}
...
socket.setEnabledProtocols(enabledProtocols);
Now, here is the catch. Oracle JDK 7 method
SSLContext.getDefaultSSLParameters().getProtocols() returns SSLv3, TLSv1
as default protocols, but if you create socket without ever calling
SSLServerSocket.setEnabledProtocols, than SSLv2Hello (pseudo protocol),
SSLv3, TLSv1, TLSv1.1, TLSv1.2 will be enabled.
This bizarre behavior from Oracle JDK 7 combined with slight difference
in Tomcat 6 and Tomcat 7 code results in different TLS/SSL protocols
being enabled by default.
What do you think, should we do anything about it? We could:
1. Patch Tomcat 6 trunk to call setEnabledProtocols always.
2. Patch Tomcat 7 trunk not to call setEnabledProtocols when protocols
are not specified.
3. Document the different behavior, and leave it as-is.
I prefer how Tomcat 6 is interpreting that attribute -- trying to enable
best possible TLS protocol versions available. That is what I would
expect as a Tomcat user.
-Ognjen
[1] http://www.mail-archive.com/users@tomcat.apache.org/msg104756.html
Bug report: https://issues.apache.org/bugzilla/show_bug.cgi?id=54690.
-Ognjen
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54690] HTTPS BIO/NIO connector does not enable TLS 1.1 and TLS 1.2 by default
https://issues.apache.org/bugzilla/show_bug.cgi?id=54690
--- Comment #1 from Ognjen Blagojevic ---
Here is a simple class to demonstrate Oracle JDK 7 behavior:
import java.net.ServerSocket;
import java.util.Arrays;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLServerSocket;
import javax.net.ssl.SSLServerSocketFactory;
public class SSLProtocolsTest {
public static void main(String[] args) throws Exception {
SSLContext context = SSLContext.getInstance("TLS");
context.init(null, null, null);
SSLServerSocketFactory sslProxy = context.getServerSocketFactory();
ServerSocket ssocket = sslProxy.createServerSocket(443);
SSLServerSocket socket = (SSLServerSocket) ssocket;
// Prints: [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]
System.out.println(" Socket enabled protocols: " +
Arrays.asList(socket.getEnabledProtocols()));
socket.setEnabledProtocols(context.getDefaultSSLParameters().getProtocols());
// Prints: [SSLv3, TLSv1]
System.out.println("Default enabled protocols: " +
Arrays.asList(socket.getEnabledProtocols()));
}
}
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54691] New: Rename HTTPS BIO/NIO connector attribute "protocols" to sslEnabledProtocols and document it.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54691 Bug ID: 54691 Summary: Rename HTTPS BIO/NIO connector attribute "protocols" to sslEnabledProtocols and document it. Product: Tomcat 6 Version: 6.0.36 Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Connectors Assignee: dev@tomcat.apache.org Reporter: ognjen.d.blagoje...@gmail.com Classification: Unclassified HTTPS BIO/NIO connector in Tomcat 7 have two attributes for protocol selection: 1. sslProtocol, to enable group of protocols, e.g. setting sslProtocol="TLSv1.1" might enable SSLv3, TLSv1 and TLSv1.1, and 2. sslEnabledProtocols, to enable specific protocols, e.g. setting sslEnabledProtocols="TLSv1,TLSv1.1" will enable only those two protocols. Tomcat 6 have one documented and one undocumented attribute: 1. sslProtocol (documented) - to enable group of protocols 2. protocols, to enable specific protocols, similar as the above. Please: 1. rename Tomcat 6 "protocols" attribute to "sslEnabledProtocols", 2. document that attribute. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
DEbug logs from v4 of your debug dll [3296] ssl_socket_send 193 bytes from 13615030 with timeout 6000 [3296] SSL_write wrote 193 bytes [3296] ssl_socket_send 4 bytes from 1772C0F0 with timeout -1 [3296] SSL_write wrote 4 bytes [3296] ssl_socket_send 8192 bytes from 1772C0F0 with timeout -1 [3296] SSL_write wrote 8192 bytes [3296] ssl_socket_send 4 bytes from 1772C0F0 with timeout -1 [3296] SSL_write wrote 4 bytes [3296] ssl_socket_send 8192 bytes from 1772C0F0 with timeout -1 [3296] SSL_write wrote 8192 bytes [3296] ssl_socket_send 4 bytes from 1772C0F0 with timeout -1 [3296] SSL_write wrote 4 bytes [3296] ssl_socket_send 8192 bytes from 1772C0F0 with timeout -1 [3296] SSL_write wrote 8192 bytes [3296] ssl_socket_send 4 bytes from 1772C0F0 with timeout -1 [3296] SSL_write returned -1, apr_get_netos_error=730035 SSL_get_error=3 [3296] ssl_socket_send 4 bytes from 16C2CFB0 with timeout -1 [3296] SSL_write returned -1, apr_get_netos_error=0 SSL_get_error=1 [3296] SSL_ERROR_SSL error in queue=336195711 [3296] bad write retry - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1456068 - in /tomcat/tc7.0.x/trunk: modules/jdbc-pool/resources/MANIFEST.MF webapps/docs/changelog.xml
Author: violetagg Date: Wed Mar 13 18:10:45 2013 New Revision: 1456068 URL: http://svn.apache.org/r1456068 Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=54684 Added 'javax.naming.spi' to the header 'Import-Package' Modified: tomcat/tc7.0.x/trunk/modules/jdbc-pool/resources/MANIFEST.MF tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Modified: tomcat/tc7.0.x/trunk/modules/jdbc-pool/resources/MANIFEST.MF URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/modules/jdbc-pool/resources/MANIFEST.MF?rev=1456068&r1=1456067&r2=1456068&view=diff == --- tomcat/tc7.0.x/trunk/modules/jdbc-pool/resources/MANIFEST.MF (original) +++ tomcat/tc7.0.x/trunk/modules/jdbc-pool/resources/MANIFEST.MF Wed Mar 13 18:10:45 2013 @@ -18,5 +18,6 @@ Import-Package: javax.management;version="0", javax.management.openmbean;version="0", javax.naming;version="0", + javax.naming.spi;version="0", javax.sql;version="0", org.apache.juli.logging;version="[6.0.18, 7.0.0)" Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1456068&r1=1456067&r2=1456068&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Wed Mar 13 18:10:45 2013 @@ -63,6 +63,16 @@ + + + +54684: Add javax.naming.spi to +Import-Package header in MANIFEST.MF in order to resolve +ClassNotFoundException when running in OSGi environment. +(violetagg) + + + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
On 13/03/2013 14:46, Mladen Turk wrote: > SSL_write is weird. Docs says that if the return value is EAGAIN the > next SSL_write *must* be called with the same params. I presume it > internally > maintains a state logic or something. Ah. I might not be doing this. Let me take a look... Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1456071 - /tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java
Author: markt
Date: Wed Mar 13 18:15:13 2013
New Revision: 1456071
URL: http://svn.apache.org/r1456071
Log:
Better comments after previous changes.
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java?rev=1456071&r1=1456070&r2=1456071&view=diff
==
---
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java
(original)
+++
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java
Wed Mar 13 18:15:13 2013
@@ -98,6 +98,9 @@ public abstract class AbstractServletOut
}
+/**
+ * Must hold writeLock to call this method.
+ */
private void writeInternal(byte[] b, int off, int len) throws IOException {
if (listener == null) {
// Simple case - blocking IO
@@ -106,9 +109,9 @@ public abstract class AbstractServletOut
// Non-blocking IO
// If the non-blocking read does not complete, doWrite() will add
// the socket back into the poller. The poller way trigger a new
-// write event before this method has finished updating buffer.
This
-// sync makes sure that buffer is updated before the next write
-// executes.
+// write event before this method has finished updating buffer. The
+// writeLock sync makes sure that buffer is updated before the next
+// write executes.
int written = doWrite(false, b, off, len);
if (written < len) {
// TODO: - Reuse the buffer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1456080 - in /tomcat/tc7.0.x/trunk: modules/jdbc-pool/resources/MANIFEST.MF webapps/docs/changelog.xml
Author: violetagg Date: Wed Mar 13 18:32:28 2013 New Revision: 1456080 URL: http://svn.apache.org/r1456080 Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52318 The version for imported package 'org.apache.juli.logging' is extended to include 7.0.x versions. Patch provided by Martin Lichtin. Modified: tomcat/tc7.0.x/trunk/modules/jdbc-pool/resources/MANIFEST.MF tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Modified: tomcat/tc7.0.x/trunk/modules/jdbc-pool/resources/MANIFEST.MF URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/modules/jdbc-pool/resources/MANIFEST.MF?rev=1456080&r1=1456079&r2=1456080&view=diff == --- tomcat/tc7.0.x/trunk/modules/jdbc-pool/resources/MANIFEST.MF (original) +++ tomcat/tc7.0.x/trunk/modules/jdbc-pool/resources/MANIFEST.MF Wed Mar 13 18:32:28 2013 @@ -20,4 +20,4 @@ Import-Package: javax.naming;version="0", javax.naming.spi;version="0", javax.sql;version="0", - org.apache.juli.logging;version="[6.0.18, 7.0.0)" + org.apache.juli.logging;version="[6.0.18, 7.1.0)" Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1456080&r1=1456079&r2=1456080&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Wed Mar 13 18:32:28 2013 @@ -71,6 +71,12 @@ ClassNotFoundException when running in OSGi environment. (violetagg) + +52318: Version for imported package +org.apache.juli.logging is extended to include also 7.0.x +versions. The fix is applicable only when running in OSGi environment. +Patch provided by Martin Lichtin. (violetagg) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1456083 - /tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
Author: violetagg
Date: Wed Mar 13 18:41:42 2013
New Revision: 1456083
URL: http://svn.apache.org/r1456083
Log:
Check that the loader is not null. There are use cases where the loader does
not have parent.
Modified:
tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java?rev=1456083&r1=1456082&r2=1456083&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/scan/StandardJarScanner.java Wed
Mar 13 18:41:42 2013
@@ -220,7 +220,7 @@ public class StandardJarScanner implemen
// already scanned WEB-INF/lib and WEB-INF/classes
ClassLoader loader = classloader.getParent();
-while (loader != stopLoader) {
+while (loader != null && loader != stopLoader) {
if (loader instanceof URLClassLoader) {
URL[] urls = ((URLClassLoader) loader).getURLs();
for (int i=0; i
Re: Strange APR/native behaviour
On 13/03/2013 18:11, Mark Thomas wrote: > On 13/03/2013 14:46, Mladen Turk wrote: > >> SSL_write is weird. Docs says that if the return value is EAGAIN the >> next SSL_write *must* be called with the same params. I presume it >> internally >> maintains a state logic or something. > > Ah. I might not be doing this. Let me take a look... I'm not but fixing that doesn't seem to help. Looking at the debug logs it appears that the APR code is taking a copy of the data since the pointer stays the same for the first few calls even though I'm using different objects in the Java code. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1456101 - /tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Author: violetagg Date: Wed Mar 13 19:31:40 2013 New Revision: 1456101 URL: http://svn.apache.org/r1456101 Log: Tag was not properly closed. Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1456101&r1=1456100&r2=1456101&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Wed Mar 13 19:31:40 2013 @@ -67,8 +67,8 @@ 54684: Add javax.naming.spi to -Import-Package header in MANIFEST.MF in order to resolve -ClassNotFoundException when running in OSGi environment. +Import-Package header in MANIFEST.MF in order to resolve +ClassNotFoundException when running in OSGi environment. (violetagg) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54693] New: Add a validationQueryTimeout property
https://issues.apache.org/bugzilla/show_bug.cgi?id=54693 Bug ID: 54693 Summary: Add a validationQueryTimeout property Product: Tomcat Modules Version: unspecified Hardware: PC Status: NEW Severity: enhancement Priority: P2 Component: jdbc-pool Assignee: dev@tomcat.apache.org Reporter: dmik...@vmware.com Classification: Unclassified While it's possible to set the query timeout using the QueryTimeoutInterceptor, this will set the same timeout for all queries. It would be nice to be able to set an independent timeout for the validation query. In addition, DBCP supports this feature [1], so it would be nice to have this feature for compatibility / migration purposes. [1] - https://issues.apache.org/jira/browse/DBCP-226 Thanks -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54693] Add a validationQueryTimeout property
https://issues.apache.org/bugzilla/show_bug.cgi?id=54693 --- Comment #1 from Daniel Mikusa --- Created attachment 30045 --> https://issues.apache.org/bugzilla/attachment.cgi?id=30045&action=edit First attempt at a patch. Attaching my first attempt at a patch. This adds a "validationQueryTimeout" property, which calls "setQueryTimeout" on the validation query's statement. Includes unittest and documentation update. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
On 03/13/2013 07:07 PM, Mark Thomas wrote: DEbug logs from v4 of your debug dll [3296] ssl_socket_send 4 bytes from 1772C0F0 with timeout -1 [3296] SSL_write returned -1, apr_get_netos_error=730035 SSL_get_error=3 [3296] ssl_socket_send 4 bytes from 16C2CFB0 with timeout -1 [3296] SSL_write returned -1, apr_get_netos_error=0 SSL_get_error=1 [3296] SSL_ERROR_SSL error in queue=336195711 [3296] bad write retry I see here that buffer change occurs. Those two calls should have the same buffer because those both calls should send the same data (since the first call reported EAGAIN) Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
On 03/13/2013 09:29 PM, Mladen Turk wrote: On 03/13/2013 07:07 PM, Mark Thomas wrote: DEbug logs from v4 of your debug dll [3296] ssl_socket_send 4 bytes from 1772C0F0 with timeout -1 [3296] SSL_write returned -1, apr_get_netos_error=730035 SSL_get_error=3 [3296] ssl_socket_send 4 bytes from 16C2CFB0 with timeout -1 [3296] SSL_write returned -1, apr_get_netos_error=0 SSL_get_error=1 [3296] SSL_ERROR_SSL error in queue=336195711 [3296] bad write retry I see here that buffer change occurs. Those two calls should have the same buffer because those both calls should send the same data (since the first call reported EAGAIN) I mean check for Socket.setsbb somewhere after the socket is returned from poller. Either the new buffer has been set or the buffer address is different because of Socket.sendbb's offset param (in this case it would be -11530560 so some wrong calculation) Inside Socket.setsbb we get the ByteBuffer's direct address and later reuse it inside Socket.sendbb(long socket, int offset, int len) call by using 'socket->jsbuff + offset' and that offseted address is displayed in the upper debug trace (and if they are not the same OpenSSL will return SSL_ERROR_SSL) Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
On 13/03/2013 20:43, Mladen Turk wrote: > On 03/13/2013 09:29 PM, Mladen Turk wrote: >> On 03/13/2013 07:07 PM, Mark Thomas wrote: >>> DEbug logs from v4 of your debug dll >>> >>> >>> [3296] ssl_socket_send 4 bytes from 1772C0F0 with timeout -1 >>> [3296] SSL_write returned -1, apr_get_netos_error=730035 SSL_get_error=3 >>> [3296] ssl_socket_send 4 bytes from 16C2CFB0 with timeout -1 >>> [3296] SSL_write returned -1, apr_get_netos_error=0 SSL_get_error=1 >>> [3296] SSL_ERROR_SSL error in queue=336195711 >>> [3296] bad write retry >>> >> >> I see here that buffer change occurs. >> Those two calls should have the same buffer because those both >> calls should send the same data (since the first call reported EAGAIN) >> > > I mean check for Socket.setsbb somewhere after the socket is > returned from poller. Either the new buffer has been set or > the buffer address is different because of Socket.sendbb's offset param > (in this case it would be -11530560 so some wrong calculation) > > Inside Socket.setsbb we get the ByteBuffer's direct address and later > reuse it inside Socket.sendbb(long socket, int offset, int len) call > by using 'socket->jsbuff + offset' and that offseted address is > displayed in > the upper debug trace (and if they are not the same OpenSSL will return > SSL_ERROR_SSL) I'm using Socket.send() with the same buffer. I'm looking at switching to sendb instead. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1456125 - /tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java
Author: markt
Date: Wed Mar 13 20:59:17 2013
New Revision: 1456125
URL: http://svn.apache.org/r1456125
Log:
Check this in before I start to work on the APR/native SSL issue
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java?rev=1456125&r1=1456124&r2=1456125&view=diff
==
---
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java
(original)
+++
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java
Wed Mar 13 20:59:17 2013
@@ -47,62 +47,75 @@ public class AprServletOutputStream exte
Lock readLock = wrapper.getBlockingStatusReadLock();
WriteLock writeLock = wrapper.getBlockingStatusWriteLock();
-boolean writeDone = false;
-int result = 0;
try {
readLock.lock();
if (wrapper.getBlockingStatus() == block) {
if (closed) {
throw new IOException(sm.getString("apr.closed"));
}
-result = Socket.send(socket, b, off, len);
-writeDone = true;
+return doWriteInternal(b, off, len);
}
} finally {
readLock.unlock();
}
-if (!writeDone) {
+try {
+writeLock.lock();
+// Set the current settings for this socket
+wrapper.setBlockingStatus(block);
+if (block) {
+Socket.timeoutSet(socket, endpoint.getSoTimeout() * 1000);
+} else {
+Socket.timeoutSet(socket, 0);
+}
+
+// Downgrade the lock
try {
-writeLock.lock();
-wrapper.setBlockingStatus(block);
-// Set the current settings for this socket
-Socket.optSet(socket, Socket.APR_SO_NONBLOCK, (block ? -1 :
0));
-// Downgrade the lock
-try {
-readLock.lock();
-writeLock.unlock();
-if (closed) {
-throw new IOException(sm.getString("apr.closed"));
-}
-result = Socket.send(socket, b, off, len);
-} finally {
-readLock.unlock();
+readLock.lock();
+writeLock.unlock();
+if (closed) {
+throw new IOException(sm.getString("apr.closed"));
}
+return doWriteInternal(b, off, len);
} finally {
-// Should have been released above but may not have been on
some
-// exception paths
-if (writeLock.isHeldByCurrentThread()) {
-writeLock.unlock();
-}
+readLock.unlock();
+}
+} finally {
+// Should have been released above but may not have been on some
+// exception paths
+if (writeLock.isHeldByCurrentThread()) {
+writeLock.unlock();
}
}
+}
+
-if (result >= 0) {
-if (result < len) {
+private int doWriteInternal(byte[] b, int off, int len) throws IOException
{
+
+int start = off;
+int left = len;
+int written;
+
+do {
+written = Socket.send(socket, b, start, left);
+if (Status.APR_STATUS_IS_EAGAIN(-written)) {
endpoint.getPoller().add(socket, -1, false, true);
+written = 0;
+} else if (written < 0) {
+throw new IOException(sm.getString("apr.write.error",
+Integer.valueOf(-written)));
}
-return result;
-} else if (-result == Status.EAGAIN) {
+start += written;
+left -= written;
+} while (written > 0 && left > 0);
+
+if (left > 0) {
endpoint.getPoller().add(socket, -1, false, true);
-return 0;
}
-
-throw new IOException(sm.getString("apr.write.error",
-Integer.valueOf(-result)));
-
+return len - left;
}
+
@Override
protected void doFlush() throws IOException {
// TODO Auto-generated method stub
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.38
I found another problem. It appears when running a web application from an archive (unpackWARs=false) Mar 14, 2013 12:01:10 AM org.apache.catalina.startup.ContextConfig processAnnotationsJndi SEVERE: Unable to process resource element [jndi:/localhost/test/WEB-INF/classes/test/servlet/servletTestServlet1.classTestServlet2.classTestServlet3.class] for annotations java.io.FileNotFoundException: jndi:/localhost/test/WEB-INF/classes/test/servlet/servletTestServlet1.classTestServlet2.classTestServlet3.class at org.apache.naming.resources.DirContextURLConnection.getInputStream(DirContextURLConnection.java:388) at org.apache.catalina.startup.ContextConfig.processAnnotationsJndi(ContextConfig.java:2041) at org.apache.catalina.startup.ContextConfig.processAnnotationsJndi(ContextConfig.java:2033) at org.apache.catalina.startup.ContextConfig.processAnnotationsJndi(ContextConfig.java:2033) at org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1949) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1307) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:878) The problem appears because the field "output" in org.apache.tomcat.util.buf.UEncoder is not cleaned properly. Regards Violeta - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
On Wed, 2013-03-13 at 20:52 +, Mark Thomas wrote: > > I mean check for Socket.setsbb somewhere after the socket is > > returned from poller. Either the new buffer has been set or > > the buffer address is different because of Socket.sendbb's offset param > > (in this case it would be -11530560 so some wrong calculation) > > > > Inside Socket.setsbb we get the ByteBuffer's direct address and later > > reuse it inside Socket.sendbb(long socket, int offset, int len) call > > by using 'socket->jsbuff + offset' and that offseted address is > > displayed in > > the upper debug trace (and if they are not the same OpenSSL will return > > SSL_ERROR_SSL) > > I'm using Socket.send() with the same buffer. > > I'm looking at switching to sendb instead. If you spare some time to refactor and use sendsbb next after trying sendb, it's supposed to be faster [I never did a real comparison test though]. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
On 13/03/2013 21:20, Remy Maucherat wrote: > On Wed, 2013-03-13 at 20:52 +, Mark Thomas wrote: >>> I mean check for Socket.setsbb somewhere after the socket is >>> returned from poller. Either the new buffer has been set or >>> the buffer address is different because of Socket.sendbb's offset param >>> (in this case it would be -11530560 so some wrong calculation) >>> >>> Inside Socket.setsbb we get the ByteBuffer's direct address and later >>> reuse it inside Socket.sendbb(long socket, int offset, int len) call >>> by using 'socket->jsbuff + offset' and that offseted address is >>> displayed in >>> the upper debug trace (and if they are not the same OpenSSL will return >>> SSL_ERROR_SSL) >> >> I'm using Socket.send() with the same buffer. >> >> I'm looking at switching to sendb instead. > > If you spare some time to refactor and use sendsbb next after trying > sendb, it's supposed to be faster [I never did a real comparison test > though]. I strongly suspect that sendb vs sendbb won't be the biggest bottleneck in my code. While I have tried not to do anything too stupid, my self imposed requirement to have WebSocket running purely on the Servlet 3.1 API without taking any short-cuts directly from WebSocket to the low-level IO has added some overhead. I'm pretty sure there is some fat that could be trimmed there. In the meantime it looks like sendb is working now I am using a directly allocated buffer. I need to do some more testing but things are (finally) looking up a bit. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1456154 - /tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java
Author: markt
Date: Wed Mar 13 21:42:16 2013
New Revision: 1456154
URL: http://svn.apache.org/r1456154
Log:
Initial fix for APR/native + SSL issues.
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java?rev=1456154&r1=1456153&r2=1456154&view=diff
==
---
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java
(original)
+++
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java
Wed Mar 13 21:42:16 2013
@@ -17,6 +17,7 @@
package org.apache.coyote.http11.upgrade;
import java.io.IOException;
+import java.nio.ByteBuffer;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantReadWriteLock.WriteLock;
@@ -27,16 +28,25 @@ import org.apache.tomcat.util.net.Socket
public class AprServletOutputStream extends AbstractServletOutputStream {
+private static final int SSL_OUTPUT_BUFFER_SIZE = 8192;
+
private final AprEndpoint endpoint;
private final SocketWrapper wrapper;
private final long socket;
private volatile boolean closed = false;
+private final ByteBuffer sslOutputBuffer;
public AprServletOutputStream(SocketWrapper wrapper,
AprEndpoint endpoint) {
this.endpoint = endpoint;
this.wrapper = wrapper;
this.socket = wrapper.getSocket().longValue();
+if (endpoint.isSSLEnabled()) {
+sslOutputBuffer =
ByteBuffer.allocateDirect(SSL_OUTPUT_BUFFER_SIZE);
+sslOutputBuffer.position(SSL_OUTPUT_BUFFER_SIZE);
+} else {
+sslOutputBuffer = null;
+}
}
@@ -97,9 +107,30 @@ public class AprServletOutputStream exte
int written;
do {
-written = Socket.send(socket, b, start, left);
+if (endpoint.isSSLEnabled()) {
+if (sslOutputBuffer.remaining() == 0) {
+// Buffer was fully written last time around
+sslOutputBuffer.clear();
+if (left < SSL_OUTPUT_BUFFER_SIZE) {
+sslOutputBuffer.put(b, start, left);
+} else {
+sslOutputBuffer.put(b, start, SSL_OUTPUT_BUFFER_SIZE);
+}
+sslOutputBuffer.flip();
+} else {
+// Buffer still has data from previous attempt to write
+// APR + SSL requires that exactly the same parameters are
+// passed when re-attempting the write
+}
+written = Socket.sendb(socket, sslOutputBuffer, start, left);
+if (written > 0) {
+sslOutputBuffer.position(
+sslOutputBuffer.position() + written);
+}
+} else {
+written = Socket.send(socket, b, start, left);
+}
if (Status.APR_STATUS_IS_EAGAIN(-written)) {
-endpoint.getPoller().add(socket, -1, false, true);
written = 0;
} else if (written < 0) {
throw new IOException(sm.getString("apr.write.error",
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1456068 - in /tomcat/tc7.0.x/trunk: modules/jdbc-pool/resources/MANIFEST.MF webapps/docs/changelog.xml
On 13/03/2013 18:10, violet...@apache.org wrote: > Author: violetagg > Date: Wed Mar 13 18:10:45 2013 > New Revision: 1456068 > > URL: http://svn.apache.org/r1456068 > Log: > Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=54684 > Added 'javax.naming.spi' to the header 'Import-Package' You need to svn merge these changes from trunk so that the merge info information is kept up to date. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1456198 - /tomcat/tc7.0.x/trunk/
Author: markt Date: Wed Mar 13 22:16:26 2013 New Revision: 1456198 URL: http://svn.apache.org/r1456198 Log: Follow-up to r1455973. Update mergeinfo Modified: tomcat/tc7.0.x/trunk/ (props changed) Propchange: tomcat/tc7.0.x/trunk/ -- Merged /tomcat/trunk:r1455854 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn propchange: r1456198 - svn:log
Author: markt Revision: 1456198 Modified property: svn:log Modified: svn:log at Wed Mar 13 22:18:09 2013 -- --- svn:log (original) +++ svn:log Wed Mar 13 22:18:09 2013 @@ -1 +1 @@ -Follow-up to r1455973. Update mergeinfo +Follow-up to r1456068. Update mergeinfo - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1456202 - /tomcat/tc7.0.x/trunk/
Author: markt Date: Wed Mar 13 22:19:01 2013 New Revision: 1456202 URL: http://svn.apache.org/r1456202 Log: Follow-up to r1456080. Update mergeinfo Modified: tomcat/tc7.0.x/trunk/ (props changed) Propchange: tomcat/tc7.0.x/trunk/ -- Merged /tomcat/trunk:r1455973 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54690] HTTPS BIO/NIO connector does not enable TLS 1.1 and TLS 1.2 by default
https://issues.apache.org/bugzilla/show_bug.cgi?id=54690 --- Comment #2 from Mark Thomas --- Note hidden in the code comments is the fact that support for SSLv2Hello is also dropped. Note that the change that triggered this bug was 54406. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "PoweredBy" by Camilanascimento
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change
notification.
The "PoweredBy" page has been changed by Camilanascimento:
http://wiki.apache.org/tomcat/PoweredBy?action=diff&rev1=458&rev2=459
=== Borneosoft ===
{{http://www.borneosoft.com/Borneosoft/_images/borneosoft4.png}}
[[http://www.borneosoft.com|Borneosoft]] - Easy-to-use Web-based CRM with Form
Builder and Admin Tools.
+ === BPG Lojas Virtuais Gratis ===
+ {{http://www.bpg.com.br/home/img/logo-bpg.png}}
[[http://www.bpg.com.br/home/|BPG]] - DYI free ecommerce platform.
+
=== BreakBIT ===
[[http://www.breakbit.com|BreakBIT]] Fairwizard - an integrated enterprise
management system for Fair and Exhibitions.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54690] HTTPS BIO/NIO connector does not enable TLS 1.1 and TLS 1.2 by default
https://issues.apache.org/bugzilla/show_bug.cgi?id=54690 --- Comment #3 from Mark Thomas --- Some issues at $work have prompted me to look into this further. Fundamentally, this is a JVM bug. I think the way forward is to use socket.getEnabledProtocols() to determine what the default protocols really are rather than using context.getDefaultSSLParameters().getProtocols() That should then be JVM neutral. We can also add a test case that will pick up if this ever gets fixed in the JVM. I'll look into patching this tomorrow. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.38
Given the issues reported with the 7.0.38 tag I'm leaning towards cancelling the 7.0.38 vote, fixing the known issues and rolling 7.0.39. In addition to the issues in Bugzilla the only other issue was the UEncoder problem Violeta found. (Any chance of a test case for that one?) Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Autobahn test results for Tomcat 8's web socket implementation
FYI http://people.apache.org/~markt/dev/autobahn-tomcat-8/ I'll post updates periodically. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1456295 - /tomcat/trunk/res/maven/mvn-pub.xml
Author: markt Date: Thu Mar 14 00:43:56 2013 New Revision: 1456295 URL: http://svn.apache.org/r1456295 Log: Fix publishing to Maven for 8.0.x Modified: tomcat/trunk/res/maven/mvn-pub.xml Modified: tomcat/trunk/res/maven/mvn-pub.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/res/maven/mvn-pub.xml?rev=1456295&r1=1456294&r2=1456295&view=diff == --- tomcat/trunk/res/maven/mvn-pub.xml (original) +++ tomcat/trunk/res/maven/mvn-pub.xml Thu Mar 14 00:43:56 2013 @@ -306,6 +306,10 @@ jarFileName="servlet-api.jar" srcJarFileName="servlet-api-src.jar"/> + + @@ -313,7 +317,6 @@ - - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Autobahn test results for Tomcat 8's web socket implementation
On Mar 13, 2013, at 6:46 PM, Mark Thomas wrote: > FYI > > http://people.apache.org/~markt/dev/autobahn-tomcat-8/ > > I'll post updates periodically. > > Mark Updates? Looks like you're done. :-) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 52318] Version in tomcat-jdbc POM is conflicted with Version in MANIFEST for JULI JAR
https://issues.apache.org/bugzilla/show_bug.cgi?id=52318 --- Comment #19 from Konstantin Kolinko --- Original issue should have been fixed by r1455973, r1456080 Issue in comment 18 still remains. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54684] PoolProperties.toString() causes NoClassDefFoundError exception
https://issues.apache.org/bugzilla/show_bug.cgi?id=54684 --- Comment #5 from Konstantin Kolinko --- Should have been fixed by r1455854 r1456068 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Strange APR/native behaviour
On 03/13/2013 10:40 PM, Mark Thomas wrote: On 13/03/2013 21:20, Remy Maucherat wrote: On Wed, 2013-03-13 at 20:52 +, Mark Thomas wrote: I mean check for Socket.setsbb somewhere after the socket is returned from poller. Either the new buffer has been set or the buffer address is different because of Socket.sendbb's offset param (in this case it would be -11530560 so some wrong calculation) Inside Socket.setsbb we get the ByteBuffer's direct address and later reuse it inside Socket.sendbb(long socket, int offset, int len) call by using 'socket->jsbuff + offset' and that offseted address is displayed in the upper debug trace (and if they are not the same OpenSSL will return SSL_ERROR_SSL) I'm using Socket.send() with the same buffer. That won't work cause each time we use different buffer either from stack (up to 8192 bytes) or malloc'd for larger ones because we need to copy from byte array. I'm looking at switching to sendb instead. If you spare some time to refactor and use sendsbb next after trying sendb, it's supposed to be faster [I never did a real comparison test though]. I strongly suspect that sendb vs sendbb won't be the biggest bottleneck in my code. There is an extra JNI call and passing object across JNI boundary uses some time. But you are right, that's not the biggest bottleneck. However like Remy said, since you have to use the same buffer anyhow and that buffer must not change its address there's no point to pass it on each call and internally call JNIEnv->GetDirectBufferAddress(buf). Just use Socket.setsbb and then Socket.sendbb. Socket.sendb is usually used for blocking sockets. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
