Re: Recent tcnative null-dereference with 8.0.0-RC3 and 7.0.45 [tcnative-1.dll+0x7e23]
On 01.10.2013 06:53, Mladen Turk wrote: > On 09/30/2013 08:50 PM, Christopher Schultz wrote: >> Mladen, >> >> Unless there is significant objection, > > Yes there is. > The transition from Java to JNI costs 10 times then > then a simple 'if (socket == OL)' in java > >> I'd like to add such NULL checks >> to limit JVM crashes in cases where the Java code isn't absolutely >> perfect (with sincere apologies to all who manage the socket-management >> code in Tomcat). >> > > -1. You are just hiding the reason for crash. I hate these crashes too, but I'm agreeing with Mladen here, especially if the native call does not return an error on such unexpected input data and the error is not handled in Java land (logging, maybe more). In cases where the crashes indicate that there was a data corruption before, like a synchronization issue, we need to get aware of that. Otherwise we might serve invalid results. It would be nice though, if there were a simple validity check in Java land, so that we could e.g. log an error if we encounter invalid data and handle the error accordingly. Regards, Rainer - 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.45
On 01/10/2013 00:29, Konstantin Preißer wrote: > Hi Mark, > > I just tested trunk with r1527733, but unfortanetly I still see the same > crashes in tcnative-1.dll. Hmm. I can't re-create these any more. Are you sure you are using the latest 8.0.x code? I do see a hang when running the unit tests so something still isn't quite right. > I also noticed that as soon as I send the first HTTP request to Tomcat, it > takes 100% CPU usage (1 thread) until the connection is closed (this is also > the case with Tomcat 8.0.0-RC3 - sorry, I didn't notice that earlier). I know why this is happening. I think this is going to need a separate thread to resolve. Mark - 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.45
Mark, On 1.10.2013 11:18, Mark Thomas wrote: I just tested trunk with r1527733, but unfortanetly I still see the same crashes in tcnative-1.dll. Hmm. I can't re-create these any more. Are you sure you are using the latest 8.0.x code? I also still get the crash with r1527985. -Ognjen - 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.45
On 01/10/2013 10:18, Mark Thomas wrote: > On 01/10/2013 00:29, Konstantin Preißer wrote: > >> Hi Mark, >> >> I just tested trunk with r1527733, but unfortanetly I still see the same >> crashes in tcnative-1.dll. > > Hmm. I can't re-create these any more. Are you sure you are using the > latest 8.0.x code? Scratch that. I can reproduce this now. Investigating... Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528060 - /tomcat/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
Author: markt
Date: Tue Oct 1 12:05:40 2013
New Revision: 1528060
URL: http://svn.apache.org/r1528060
Log:
Better log message for socket destruction and remove reference to deleted
parameter
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties?rev=1528060&r1=1528059&r2=1528060&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
Tue Oct 1 12:05:40 2013
@@ -24,7 +24,7 @@ endpoint.warn.noInsecureReneg=Secure re-
endpoint.warn.unlockAcceptorFailed=Acceptor thread [{0}] failed to unlock.
Forcing hard socket shutdown.
endpoint.warn.executorShutdown=The executor associated with thread pool [{0}]
has not fully shutdown. Some application threads may still be running.
endpoint.debug.channelCloseFail=Failed to close channel
-endpoint.debug.destroySocket=socket [{0}], doIt [{1}]
+endpoint.debug.destroySocket=Destroying socket [{0}]
endpoint.debug.pollerAdd=Add to addList socket [{0}], timeout [{1}], flags
[{2}]
endpoint.debug.pollerAddDo=Add to poller socket [{0}]
endpoint.debug.pollerProcess=Processing socket [{0}] for event(s) [{1}]
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-240) Artifacts with same artifactID but different groupID are skipped
[
https://issues.apache.org/jira/browse/MTOMCAT-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13782855#comment-13782855
]
Olivier Lamy (*$^¨%`£) commented on MTOMCAT-240:
I wonder if more than one jars have the same how does it when the files are
packaged in WEB-INF/lib ?
> Artifacts with same artifactID but different groupID are skipped
>
>
> Key: MTOMCAT-240
> URL: https://issues.apache.org/jira/browse/MTOMCAT-240
> Project: Apache Tomcat Maven Plugin
> Issue Type: Bug
> Components: commons-lib
>Affects Versions: 2.1
> Environment: all
>Reporter: Petar Tahchiev
>Assignee: Olivier Lamy (*$^¨%`£)
> Fix For: 2.2
>
> Attachments: MTOMCAT-240.patch
>
>
> Hi guys,
> I have the following situation: my classpath includes the following artifacts:
> 1) artifactA in group com.mygroup
> 2) artifactA in group com.myothergroup.
> Looking in DefaultClassLoaderEntriesCalculator.java on line 120 we see the
> following:
> {code}
> String fileName = artifact.getFile().getName();
> if ( !fileInClassLoaderEntries.contains( fileName ) )
> {
>// add the artifact to the classpath
> }
> {code}
> So in my case both artifacts are resolved as artifactA-1.0-SNAPSHOT.jar so
> the second one gets omitted. I have chaged to code to simply include the
> categoryID like this:
> {code}
> String fileName = artifact.getGroupId() + "-" +
> artifact.getFile().getName();
> if ( !fileInClassLoaderEntries.contains( fileName ) )
> {
> //add to classpath
> }
> {code}
> and it works like a charm.
> You can find the patch attached. Please review it and apply.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-240) Artifacts with same artifactID but different groupID are skipped
[
https://issues.apache.org/jira/browse/MTOMCAT-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13782866#comment-13782866
]
Petar Tahchiev commented on MTOMCAT-240:
It copies both, but changes their names (prepends the groupId). In WEB-INF/lib
I see:
{code}
com.x.foo-core-0.6-SNAPSHOT.jar
com.yyy.bar-core-0.6-SNAPSHOT.jar
{code}
> Artifacts with same artifactID but different groupID are skipped
>
>
> Key: MTOMCAT-240
> URL: https://issues.apache.org/jira/browse/MTOMCAT-240
> Project: Apache Tomcat Maven Plugin
> Issue Type: Bug
> Components: commons-lib
>Affects Versions: 2.1
> Environment: all
>Reporter: Petar Tahchiev
>Assignee: Olivier Lamy (*$^¨%`£)
> Fix For: 2.2
>
> Attachments: MTOMCAT-240.patch
>
>
> Hi guys,
> I have the following situation: my classpath includes the following artifacts:
> 1) artifactA in group com.mygroup
> 2) artifactA in group com.myothergroup.
> Looking in DefaultClassLoaderEntriesCalculator.java on line 120 we see the
> following:
> {code}
> String fileName = artifact.getFile().getName();
> if ( !fileInClassLoaderEntries.contains( fileName ) )
> {
>// add the artifact to the classpath
> }
> {code}
> So in my case both artifacts are resolved as artifactA-1.0-SNAPSHOT.jar so
> the second one gets omitted. I have chaged to code to simply include the
> categoryID like this:
> {code}
> String fileName = artifact.getGroupId() + "-" +
> artifact.getFile().getName();
> if ( !fileInClassLoaderEntries.contains( fileName ) )
> {
> //add to classpath
> }
> {code}
> and it works like a charm.
> You can find the patch attached. Please review it and apply.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-240) Artifacts with same artifactID but different groupID are skipped
[
https://issues.apache.org/jira/browse/MTOMCAT-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13782870#comment-13782870
]
Olivier Lamy (*$^¨%`£) commented on MTOMCAT-240:
doh I didn't know war plugin do that.
> Artifacts with same artifactID but different groupID are skipped
>
>
> Key: MTOMCAT-240
> URL: https://issues.apache.org/jira/browse/MTOMCAT-240
> Project: Apache Tomcat Maven Plugin
> Issue Type: Bug
> Components: commons-lib
>Affects Versions: 2.1
> Environment: all
>Reporter: Petar Tahchiev
>Assignee: Olivier Lamy (*$^¨%`£)
> Fix For: 2.2
>
> Attachments: MTOMCAT-240.patch
>
>
> Hi guys,
> I have the following situation: my classpath includes the following artifacts:
> 1) artifactA in group com.mygroup
> 2) artifactA in group com.myothergroup.
> Looking in DefaultClassLoaderEntriesCalculator.java on line 120 we see the
> following:
> {code}
> String fileName = artifact.getFile().getName();
> if ( !fileInClassLoaderEntries.contains( fileName ) )
> {
>// add the artifact to the classpath
> }
> {code}
> So in my case both artifacts are resolved as artifactA-1.0-SNAPSHOT.jar so
> the second one gets omitted. I have chaged to code to simply include the
> categoryID like this:
> {code}
> String fileName = artifact.getGroupId() + "-" +
> artifact.getFile().getName();
> if ( !fileInClassLoaderEntries.contains( fileName ) )
> {
> //add to classpath
> }
> {code}
> and it works like a charm.
> You can find the patch attached. Please review it and apply.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528074 - /tomcat/maven-plugin/trunk/pom.xml
Author: olamy Date: Tue Oct 1 12:57:55 2013 New Revision: 1528074 URL: http://svn.apache.org/r1528074 Log: add contributor Modified: tomcat/maven-plugin/trunk/pom.xml Modified: tomcat/maven-plugin/trunk/pom.xml URL: http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/pom.xml?rev=1528074&r1=1528073&r2=1528074&view=diff == --- tomcat/maven-plugin/trunk/pom.xml (original) +++ tomcat/maven-plugin/trunk/pom.xml Tue Oct 1 12:57:55 2013 @@ -158,6 +158,9 @@ Daniel Cassidy + + Petar Tahchiev + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528073 - /tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
Author: olamy
Date: Tue Oct 1 12:57:44 2013
New Revision: 1528073
URL: http://svn.apache.org/r1528073
Log:
[MTOMCAT-240] Artifacts with same artifactID but different groupID are skipped
Submitted by Petar Tahchiev
Modified:
tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
Modified:
tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
URL:
http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java?rev=1528073&r1=1528072&r2=1528073&view=diff
==
---
tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
(original)
+++
tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
Tue Oct 1 12:57:44 2013
@@ -117,7 +117,7 @@ public class DefaultClassLoaderEntriesCa
// so artifact.getFile is a file not a directory and not
added when iterate on project.classPathElements
if ( !isInProjectReferences( artifact,
request.getMavenProject() ) || artifact.getFile().isFile() )
{
-String fileName = artifact.getFile().getName();
+String fileName = artifact.getGroupId() + "-" +
artifact.getFile().getName();
if ( !fileInClassLoaderEntries.contains( fileName ) )
{
classLoaderEntries.add(
artifact.getFile().toURI().toString() );
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Closed] (MTOMCAT-240) Artifacts with same artifactID but different groupID are skipped
[
https://issues.apache.org/jira/browse/MTOMCAT-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy (*$^¨%`£) closed MTOMCAT-240.
--
Resolution: Fixed
patch applied.
Thanks!
> Artifacts with same artifactID but different groupID are skipped
>
>
> Key: MTOMCAT-240
> URL: https://issues.apache.org/jira/browse/MTOMCAT-240
> Project: Apache Tomcat Maven Plugin
> Issue Type: Bug
> Components: commons-lib
>Affects Versions: 2.1
> Environment: all
>Reporter: Petar Tahchiev
>Assignee: Olivier Lamy (*$^¨%`£)
> Fix For: 2.2
>
> Attachments: MTOMCAT-240.patch
>
>
> Hi guys,
> I have the following situation: my classpath includes the following artifacts:
> 1) artifactA in group com.mygroup
> 2) artifactA in group com.myothergroup.
> Looking in DefaultClassLoaderEntriesCalculator.java on line 120 we see the
> following:
> {code}
> String fileName = artifact.getFile().getName();
> if ( !fileInClassLoaderEntries.contains( fileName ) )
> {
>// add the artifact to the classpath
> }
> {code}
> So in my case both artifacts are resolved as artifactA-1.0-SNAPSHOT.jar so
> the second one gets omitted. I have chaged to code to simply include the
> categoryID like this:
> {code}
> String fileName = artifact.getGroupId() + "-" +
> artifact.getFile().getName();
> if ( !fileInClassLoaderEntries.contains( fileName ) )
> {
> //add to classpath
> }
> {code}
> and it works like a charm.
> You can find the patch attached. Please review it and apply.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot failure in ASF Buildbot on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/5028 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1528060 Blamelist: markt BUILD FAILED: failed compile_1 sincerely, -The Buildbot
[jira] [Commented] (MTOMCAT-240) Artifacts with same artifactID but different groupID are skipped
[
https://issues.apache.org/jira/browse/MTOMCAT-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13782909#comment-13782909
]
Hudson commented on MTOMCAT-240:
SUCCESS: Integrated in TomcatMavenPlugin-mvn3.x #256 (See
[https://builds.apache.org/job/TomcatMavenPlugin-mvn3.x/256/])
[MTOMCAT-240] Artifacts with same artifactID but different groupID are skipped
Submitted by Petar Tahchiev (olamy:
http://svn.apache.org/viewvc/?view=rev&rev=1528073)
*
/tomcat/maven-plugin/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
> Artifacts with same artifactID but different groupID are skipped
>
>
> Key: MTOMCAT-240
> URL: https://issues.apache.org/jira/browse/MTOMCAT-240
> Project: Apache Tomcat Maven Plugin
> Issue Type: Bug
> Components: commons-lib
>Affects Versions: 2.1
> Environment: all
>Reporter: Petar Tahchiev
>Assignee: Olivier Lamy (*$^¨%`£)
> Fix For: 2.2
>
> Attachments: MTOMCAT-240.patch
>
>
> Hi guys,
> I have the following situation: my classpath includes the following artifacts:
> 1) artifactA in group com.mygroup
> 2) artifactA in group com.myothergroup.
> Looking in DefaultClassLoaderEntriesCalculator.java on line 120 we see the
> following:
> {code}
> String fileName = artifact.getFile().getName();
> if ( !fileInClassLoaderEntries.contains( fileName ) )
> {
>// add the artifact to the classpath
> }
> {code}
> So in my case both artifacts are resolved as artifactA-1.0-SNAPSHOT.jar so
> the second one gets omitted. I have chaged to code to simply include the
> categoryID like this:
> {code}
> String fileName = artifact.getGroupId() + "-" +
> artifact.getFile().getName();
> if ( !fileInClassLoaderEntries.contains( fileName ) )
> {
> //add to classpath
> }
> {code}
> and it works like a charm.
> You can find the patch attached. Please review it and apply.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Recent tcnative null-dereference with 8.0.0-RC3 and 7.0.45 [tcnative-1.dll+0x7e23]
Mladen and Rainer, On 10/1/13 2:59 AM, Rainer Jung wrote: > On 01.10.2013 06:53, Mladen Turk wrote: >> On 09/30/2013 08:50 PM, Christopher Schultz wrote: >>> Mladen, >>> >>> Unless there is significant objection, >> >> Yes there is. >> The transition from Java to JNI costs 10 times then >> then a simple 'if (socket == OL)' in java Okay, so we can add those in Java as well. I still think that tcnative should be coded defensively. >>> I'd like to add such NULL checks >>> to limit JVM crashes in cases where the Java code isn't absolutely >>> perfect (with sincere apologies to all who manage the socket-management >>> code in Tomcat). >>> >> >> -1. You are just hiding the reason for crash. I disagree: the reason for the crash can still be reported. It just won't be reported with a JVM crash: instead, there will be an exception. We can even rig it to report the line number in the native method if you want. Wouldn't that be better than bringing-down the whole JVM? I'd rather have a complete lock-up of the JVM with a handful of exceptions explaining the problem than having to examine a core file to figure out what happened. I'm sure that's true of most of our users, too. > I hate these crashes too, but I'm agreeing with Mladen here, especially > if the native call does not return an error on such unexpected input > data and the error is not handled in Java land (logging, maybe more). I wasn't suggesting that the Java component take no action, here: I was just suggesting that a exception (even if fatal) is better than a JVM crash. I don't see why both components can't check their own stuff. > In cases where the crashes indicate that there was a data corruption > before, like a synchronization issue, we need to get aware of that. > Otherwise we might serve invalid results. > > It would be nice though, if there were a simple validity check in Java > land, so that we could e.g. log an error if we encounter invalid data > and handle the error accordingly. We can add those, too. I'm trying to understand which data are intended to be native pointers so we can do that kind of thing. I'm happy to add zero-checks in Java as well as NULL checks in the native code. I just didn't want to go around changing things in Java-land if Mark is doing the same: his changes will likely be more meaningful than anything I do. -chris signature.asc Description: OpenPGP digital signature
Re: Recent tcnative null-dereference with 8.0.0-RC3 and 7.0.45 [tcnative-1.dll+0x7e23]
On 10/01/2013 04:15 PM, Christopher Schultz wrote: Mladen and Rainer, -1. You are just hiding the reason for crash. I disagree: the reason for the crash can still be reported. It just won't be reported with a JVM crash: instead, there will be an exception. I disagree on your disagreement :) This can be easily done in Java with much cheaper computing cost. If you suspect the data fed to native call can be faulty, well check it and throw java exception instead calling native, and distinguishing between valid and error return values from native and then still have a code which will pass/throw. I know it requires a different thinking then average library, but it's not an average library. It's wrapper for APR and APR expects you provide valid data. Even checking in native won't solve crashes. You can fed a long (pointer) which is in zombie state (closed but not null) and you'll have a memory location which will pass null check but can still crash or even corrupt other memory location if it was reused by another alloc. Much harder to track down. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Recent tcnative null-dereference with 8.0.0-RC3 and 7.0.45 [tcnative-1.dll+0x7e23]
Mladen, On 10/1/13 10:39 AM, Mladen Turk wrote: > On 10/01/2013 04:15 PM, Christopher Schultz wrote: >> Mladen and Rainer, -1. You are just hiding the reason for crash. >> >> I disagree: the reason for the crash can still be reported. It just >> won't be reported with a JVM crash: instead, there will be an exception. > > I disagree on your disagreement :) ;) Just to be sure: I'm not arguing against fixing the Java code, or providing checks in the Java code to avoid SIGSEGVs. I'm just saying that native code should be as safe as reasonably possible. NULL-checks are cheap, too, so I don't think there's any reason to avoid them in native code. > This can be easily done in Java with much cheaper computing cost. Agreed. Feel free to avoid native calls if you know the data is bad. But we can't force people to use specific versions of Tomcat and tcnative together (though obviously, newer versions of Tomcat can refuse to load older versions of tcnative). Someone pointed out in Bugzilla (though it mostly fell on deaf ears) that tcnative isn't used exclusively for Tomcat: some folks are using it as a convenient library to access APR and other native capabilities in a Java wrapper. > If you suspect the data fed to native call can be faulty, well check it > and throw java exception instead calling native, and distinguishing > between valid > and error return values from native and then still have a code which will > pass/throw. I was suggesting throwing an exception directly from native code, not trying to return a status code and then throwing from Java-land. > I know it requires a different thinking then average library, > but it's not an average library. It's wrapper for APR and APR expects you > provide valid data. > > Even checking in native won't solve crashes. You can fed a long (pointer) > which is in zombie state (closed but not null) and you'll have a memory > location which will pass null check but can still crash or even corrupt > other memory location if it was reused by another alloc. Sure, but a NULL-check (whether in Java or C) isn't going to catch that either way, and nothing we've been discussing here will have any bearing on that situation: it will still fail, it will likely still crash or behave strangely and ... > Much harder to track down. ... it will be hard to track down. Adding NULL-checks will not complicate any of that. It will not mask any of that. It will make it no more difficult to track-down or debug. It will only prevent the JVM going down when a pointer ends up being NULL, which is the only reason I'm suggesting it. Given the two -1s and lack of any +1s on this suggestion, I won't be committing anything, but I still think it's a worthwhile endeavor because it's so easy to do and protects us from such disastrous results. -chris signature.asc Description: OpenPGP digital signature
Need to test build of tc native 1.1.x
I think one of the current issues has been fixed in 1.1.x. I'm trying to build it locally but if anyone who has a build env to hand to build a AMD 64-bit tc-native dll for me that would be a big help. Thanks, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 45067] UDecoder.java stack dumps on valid URL encoding
https://issues.apache.org/bugzilla/show_bug.cgi?id=45067 ankaraju.devath...@gmail.com changed: What|Removed |Added Hardware|PC |All OS|Windows XP |Linux -- 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: Need to test build of tc native 1.1.x
On 10/01/2013 05:03 PM, Mark Thomas wrote: I think one of the current issues has been fixed in 1.1.x. I'm trying to build it locally but if anyone who has a build env to hand to build a AMD 64-bit tc-native dll for me that would be a big help. Give one hour. I have the env. Cheers -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Need to test build of tc native 1.1.x
On 10/01/2013 05:03 PM, Mark Thomas wrote: I think one of the current issues has been fixed in 1.1.x. I'm trying to build it locally but if anyone who has a build env to hand to build a AMD 64-bit tc-native dll for me that would be a big help. Here you go http://people.apache.org/~mturk/native/tomcat-native-win32-x86_64-r1528132.zip Cheers -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528140 - /tomcat/trunk/webapps/docs/images/docs-stylesheet.css
Author: kpreisser
Date: Tue Oct 1 16:35:39 2013
New Revision: 1528140
URL: http://svn.apache.org/r1528140
Log:
Fix style for element in comments section.
Modified:
tomcat/trunk/webapps/docs/images/docs-stylesheet.css
Modified: tomcat/trunk/webapps/docs/images/docs-stylesheet.css
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/images/docs-stylesheet.css?rev=1528140&r1=1528139&r2=1528140&view=diff
==
--- tomcat/trunk/webapps/docs/images/docs-stylesheet.css (original)
+++ tomcat/trunk/webapps/docs/images/docs-stylesheet.css Tue Oct 1 16:35:39
2013
@@ -284,4 +284,10 @@ ul.changelog img {
.noPrint { display: none; }
#middle > div > div#mainLeft { display: none; }
a { color: inherit; text-decoration: none; }
+}
+
+/* Fix for Comments section which contains a */
+#comments_thread h1, #comments_thread h2, #comments_thread h3,
#comments_thread h4, #comments_thread h5, #comments_thread h6 {
+border: none;
+ background-color: transparent;
}
\ No newline at end of file
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528141 - /tomcat/trunk/webapps/docs/images/docs-stylesheet.css
Author: kpreisser
Date: Tue Oct 1 16:37:43 2013
New Revision: 1528141
URL: http://svn.apache.org/r1528141
Log:
Replace tab with spaces
Modified:
tomcat/trunk/webapps/docs/images/docs-stylesheet.css
Modified: tomcat/trunk/webapps/docs/images/docs-stylesheet.css
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/images/docs-stylesheet.css?rev=1528141&r1=1528140&r2=1528141&view=diff
==
--- tomcat/trunk/webapps/docs/images/docs-stylesheet.css (original)
+++ tomcat/trunk/webapps/docs/images/docs-stylesheet.css Tue Oct 1 16:37:43
2013
@@ -289,5 +289,5 @@ ul.changelog img {
/* Fix for Comments section which contains a */
#comments_thread h1, #comments_thread h2, #comments_thread h3,
#comments_thread h4, #comments_thread h5, #comments_thread h6 {
border: none;
- background-color: transparent;
+background-color: transparent;
}
\ No newline at end of file
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Need to test build of tc native 1.1.x
On 01/10/2013 17:21, Mladen Turk wrote: > On 10/01/2013 05:03 PM, Mark Thomas wrote: >> I think one of the current issues has been fixed in 1.1.x. I'm trying to >> build it locally but if anyone who has a build env to hand to build a >> AMD 64-bit tc-native dll for me that would be a big help. >> > > Here you go > http://people.apache.org/~mturk/native/tomcat-native-win32-x86_64-r1528132.zip You forgot to make the file public readable so I used my infra karma to fix that :) Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Need to test build of tc native 1.1.x
On 01/10/2013 17:46, Mark Thomas wrote: > On 01/10/2013 17:21, Mladen Turk wrote: >> On 10/01/2013 05:03 PM, Mark Thomas wrote: >>> I think one of the current issues has been fixed in 1.1.x. I'm trying to >>> build it locally but if anyone who has a build env to hand to build a >>> AMD 64-bit tc-native dll for me that would be a big help. >>> >> >> Here you go >> http://people.apache.org/~mturk/native/tomcat-native-win32-x86_64-r1528132.zip > > You forgot to make the file public readable so I used my infra karma to > fix that :) And I forgot to say thanks. That is extremely helpful. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Need to test build of tc native 1.1.x
On 10/01/2013 06:46 PM, Mark Thomas wrote: Here you go http://people.apache.org/~mturk/native/tomcat-native-win32-x86_64-r1528132.zip You forgot to make the file public readable so I used my infra karma to fix that :) Yeah, I always forget that sftp from samba drive sets weird privs. Glad it worked at the end. Cheers -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Recent tcnative null-dereference with 8.0.0-RC3 and 7.0.45 [tcnative-1.dll+0x7e23]
On 1 October 2013 15:47, Christopher Schultz wrote: > Mladen, > > On 10/1/13 10:39 AM, Mladen Turk wrote: >> On 10/01/2013 04:15 PM, Christopher Schultz wrote: >>> Mladen and Rainer, > > -1. You are just hiding the reason for crash. >>> >>> I disagree: the reason for the crash can still be reported. It just >>> won't be reported with a JVM crash: instead, there will be an exception. >> >> I disagree on your disagreement :) > > ;) > > Just to be sure: I'm not arguing against fixing the Java code, or > providing checks in the Java code to avoid SIGSEGVs. I'm just saying > that native code should be as safe as reasonably possible. NULL-checks > are cheap, too, so I don't think there's any reason to avoid them in > native code. > >> This can be easily done in Java with much cheaper computing cost. > > Agreed. Feel free to avoid native calls if you know the data is bad. But > we can't force people to use specific versions of Tomcat and tcnative > together (though obviously, newer versions of Tomcat can refuse to load > older versions of tcnative). Someone pointed out in Bugzilla (though it > mostly fell on deaf ears) that tcnative isn't used exclusively for > Tomcat: some folks are using it as a convenient library to access APR > and other native capabilities in a Java wrapper. > >> If you suspect the data fed to native call can be faulty, well check it >> and throw java exception instead calling native, and distinguishing >> between valid >> and error return values from native and then still have a code which will >> pass/throw. > > I was suggesting throwing an exception directly from native code, not > trying to return a status code and then throwing from Java-land. > >> I know it requires a different thinking then average library, >> but it's not an average library. It's wrapper for APR and APR expects you >> provide valid data. >> >> Even checking in native won't solve crashes. You can fed a long (pointer) >> which is in zombie state (closed but not null) and you'll have a memory >> location which will pass null check but can still crash or even corrupt >> other memory location if it was reused by another alloc. > > Sure, but a NULL-check (whether in Java or C) isn't going to catch that > either way, and nothing we've been discussing here will have any bearing > on that situation: it will still fail, it will likely still crash or > behave strangely and ... > >> Much harder to track down. > > ... it will be hard to track down. Adding NULL-checks will not > complicate any of that. It will not mask any of that. It will make it no > more difficult to track-down or debug. It will only prevent the JVM > going down when a pointer ends up being NULL, which is the only reason > I'm suggesting it. > > Given the two -1s and lack of any +1s on this suggestion, I won't be > committing anything, but I still think it's a worthwhile endeavor > because it's so easy to do and protects us from such disastrous results. +1 (non-binding!) I agree with Mladen that relying on tcnative to do all the validation is wrong; the Java code should be written so as to only pass valid parameters. But mistakes happen, and not all applications using tcnative are written by Tomcat developers who should be familiar with the calling conventions. The JVM throws an exception if a Java application uses an invalid array index or tries to read past the end of an iterator. That does not mean that Java applications should use these exceptions as part of standard coding; of course the application should try to use valid parameters. The point is that such exceptions make debugging much easier. If Java crashed whenever an invalid parameter was provided, it would not be very popular with developers. If a Java application succeeds in crashing the JVM, then IMO the JVM has a bug. I believe that all native code should strive to behave the same way. > -chris > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot success in ASF Buildbot on tomcat-trunk
The Buildbot has detected a restored build on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/5029 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1528141 Blamelist: kpreisser Build succeeded! sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528158 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/tomcat/util/net/res/LocalStrings.properties
Author: markt
Date: Tue Oct 1 17:49:49 2013
New Revision: 1528158
URL: http://svn.apache.org/r1528158
Log:
Better log message for socket destruction and remove reference to deleted
parameter
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1528060
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties?rev=1528158&r1=1528157&r2=1528158&view=diff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
(original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
Tue Oct 1 17:49:49 2013
@@ -24,7 +24,7 @@ endpoint.warn.noInsecureReneg=Secure re-
endpoint.warn.unlockAcceptorFailed=Acceptor thread [{0}] failed to unlock.
Forcing hard socket shutdown.
endpoint.warn.executorShutdown=The executor associated with thread pool [{0}]
has not fully shutdown. Some application threads may still be running.
endpoint.debug.channelCloseFail=Failed to close channel
-endpoint.debug.destroySocket=socket [{0}], doIt [{1}]
+endpoint.debug.destroySocket=Destroying socket [{0}]
endpoint.debug.pollerAdd=Add to addList socket [{0}], timeout [{1}], flags
[{2}]
endpoint.debug.pollerAddDo=Add to poller socket [{0}]
endpoint.debug.pollerProcess=Processing socket [{0}] for event(s) [{1}]
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528166 - /tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Author: markt
Date: Tue Oct 1 18:13:30 2013
New Revision: 1528166
URL: http://svn.apache.org/r1528166
Log:
Ensure that connectionCount remains thread-safe
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1528166&r1=1528165&r2=1528166&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Tue Oct 1
18:13:30 2013
@@ -27,6 +27,7 @@ import java.util.concurrent.ConcurrentHa
import java.util.concurrent.ConcurrentLinkedQueue;
import java.util.concurrent.Executor;
import java.util.concurrent.RejectedExecutionException;
+import java.util.concurrent.atomic.AtomicInteger;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
@@ -1315,10 +1316,17 @@ public class AprEndpoint extends Abstrac
/**
- * Amount of connections inside this poller.
+ * The number of connections currently inside this Poller. The correct
+ * operation of the Poller depends on this figure being correct. If it
+ * is not, it is possible that the Poller will enter a wait loop where
+ * it waits for the next connection to be added to the Poller before it
+ * calls poll when it should still be polling existing connections.
+ * Although not necessary at the time of writing this comment, it has
+ * been implemented as an AtomicInteger to ensure that it remains
+ * thread-safe.
*/
-private int connectionCount = 0;
-public int getConnectionCount() { return connectionCount; }
+private AtomicInteger connectionCount = new AtomicInteger(0);
+public int getConnectionCount() { return connectionCount.get(); }
private volatile boolean pollerRunning = true;
@@ -1374,7 +1382,7 @@ public class AprEndpoint extends Abstrac
}
desc = new long[actualPollerSize * 2];
-connectionCount = 0;
+connectionCount.set(0);
addList = new SocketList(defaultPollerSize);
closeList = new SocketList(defaultPollerSize);
}
@@ -1433,7 +1441,7 @@ public class AprEndpoint extends Abstrac
}
}
Pool.destroy(pool);
-connectionCount = 0;
+connectionCount.set(0);
}
@@ -1506,7 +1514,7 @@ public class AprEndpoint extends Abstrac
rv = Poll.add(pollers[i], socket, events);
if (rv == Status.APR_SUCCESS) {
pollerSpace[i]--;
-connectionCount++;
+connectionCount.incrementAndGet();
return true;
}
}
@@ -1540,7 +1548,7 @@ public class AprEndpoint extends Abstrac
rv = Poll.remove(pollers[i], socket);
if (rv != Status.APR_NOTFOUND) {
pollerSpace[i]++;
-connectionCount--;
+connectionCount.decrementAndGet();
break;
}
}
@@ -1622,7 +1630,7 @@ public class AprEndpoint extends Abstrac
}
}
// Check timeouts if the poller is empty
-while (pollerRunning && connectionCount < 1 &&
+while (pollerRunning && connectionCount.get() < 1 &&
addList.size() < 1) {
// Reset maintain time.
try {
@@ -1739,7 +1747,7 @@ public class AprEndpoint extends Abstrac
}
if (rv > 0) {
pollerSpace[i] += rv;
-connectionCount -= rv;
+connectionCount.addAndGet(-rv);
for (int n = 0; n < rv; n++) {
timeouts.remove(desc[n*2+1]);
AprSocketWrapper wrapper = connections.get(
@@ -1882,7 +1890,7 @@ public class AprEndpoint extends Abstrac
long newPoller = allocatePoller(actualPollerSize,
pool, -1);
// Don't restore connections for now, since I have
not tested it
pollerSpace[i] = actualPollerSize;
-connectionCount -= count;
+connectionCount.addAndGet(-count);
Poll.destroy(pollers[i]);
pollers[i] = newPoller;
}
-
To unsubscribe, e-
svn commit: r1528169 - /tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Author: markt
Date: Tue Oct 1 18:19:21 2013
New Revision: 1528169
URL: http://svn.apache.org/r1528169
Log:
If there are sockets to close, close them rather than waiting for the
next Poller run.
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1528169&r1=1528168&r2=1528169&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Tue Oct 1
18:19:21 2013
@@ -1631,7 +1631,7 @@ public class AprEndpoint extends Abstrac
}
// Check timeouts if the poller is empty
while (pollerRunning && connectionCount.get() < 1 &&
-addList.size() < 1) {
+addList.size() < 1 && closeList.size() < 1) {
// Reset maintain time.
try {
if (getSoTimeout() > 0 && pollerRunning) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528171 - /tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Author: markt
Date: Tue Oct 1 18:27:42 2013
New Revision: 1528171
URL: http://svn.apache.org/r1528171
Log:
Address issue reported with high CPU usage under low load load.
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1528171&r1=1528170&r2=1528171&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Tue Oct 1
18:27:42 2013
@@ -1282,6 +1282,13 @@ public class AprEndpoint extends Abstrac
private int pollerTime;
/**
+ * Variable poller timeout that adjusts depending on how many poll sets
+ * are in use so that the total poll time across all poll sets remains
+ * equal to pollTime.
+ */
+private int nextPollerTime;
+
+/**
* Root pool.
*/
private long pool = 0;
@@ -1369,6 +1376,7 @@ public class AprEndpoint extends Abstrac
pollerCount = defaultPollerSize / actualPollerSize;
pollerTime = pollTime / pollerCount;
+nextPollerTime = pollerTime;
pollers = new long[pollerCount];
pollers[0] = pollset;
@@ -1743,7 +1751,18 @@ public class AprEndpoint extends Abstrac
int rv = 0;
// Iterate on each pollers, but no need to poll empty
pollers
if (pollerSpace[i] < actualPollerSize) {
-rv = Poll.poll(pollers[i], pollerTime, desc, true);
+rv = Poll.poll(pollers[i], nextPollerTime, desc,
true);
+// Reset the nextPollerTime
+nextPollerTime = pollerTime;
+} else {
+// Skipping an empty poll set means skipping a wait
+// time of pollerTime microseconds. If most of the
+// poll sets are skipped then this loop will be
+// tighter than expected which could lead to higher
+// than expected CPU usage. Extending the
+// nextPollerTime ensures that this loop always
+// takes about the same time to execute.
+nextPollerTime += pollerTime;
}
if (rv > 0) {
pollerSpace[i] += rv;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528172 - in /tomcat/trunk/java/org/apache/tomcat/util/net: AprEndpoint.java res/LocalStrings.properties
Author: markt
Date: Tue Oct 1 18:28:42 2013
New Revision: 1528172
URL: http://svn.apache.org/r1528172
Log:
More debug logging for the APR/native connector.
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1528172&r1=1528171&r2=1528172&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Tue Oct 1
18:28:42 2013
@@ -1550,6 +1550,10 @@ public class AprEndpoint extends Abstrac
* {@link Poller#run()}.
*/
private boolean removeFromPoller(long socket) {
+if (log.isDebugEnabled()) {
+log.debug(sm.getString("endpoint.debug.pollerRemove",
+Long.valueOf(socket)));
+}
int rv = -1;
for (int i = 0; i < pollers.length; i++) {
if (pollerSpace[i] < actualPollerSize) {
@@ -1557,6 +1561,10 @@ public class AprEndpoint extends Abstrac
if (rv != Status.APR_NOTFOUND) {
pollerSpace[i]++;
connectionCount.decrementAndGet();
+if (log.isDebugEnabled()) {
+
log.debug(sm.getString("endpoint.debug.pollerRemoved",
+Long.valueOf(socket)));
+}
break;
}
}
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties?rev=1528172&r1=1528171&r2=1528172&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
Tue Oct 1 18:28:42 2013
@@ -28,6 +28,8 @@ endpoint.debug.destroySocket=Destroying
endpoint.debug.pollerAdd=Add to addList socket [{0}], timeout [{1}], flags
[{2}]
endpoint.debug.pollerAddDo=Add to poller socket [{0}]
endpoint.debug.pollerProcess=Processing socket [{0}] for event(s) [{1}]
+endpoint.debug.pollerRemove=Attempting to remove [{0}] from poller
+endpoint.debug.pollerRemoved=Removed [{0}] from poller
endpoint.debug.socket=socket [{0}]
endpoint.debug.socketCloseFail=Failed to close socket
endpoint.debug.socketTimeout=Timing out [{0}]
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
8.0.x / 7.0.x progress
Pulling together information from multiple threads: 8.0.x trunk appears to be stable (i.e. no longer crashes) but the FormAuthenticator unit tests are very slow (24 minutes). This needs to be resolved. I will port the latest APR changes to 7.0.x shortly. A build of the latest 1.1.x tomcat-native code is required to achieve that stability. The implication is that a 1.1.29 release will be required before the next 7.0.x release. The issue with the FormAuthenticator needs to be resolved before the tomcat-native 1.1.29 release in case further native code changes are required. The unit tests have identified a rare failure mode in JULI during context stop: http://ci.apache.org/projects/tomcat/tomcat7/logs/1527504/TEST-org.apache.catalina.websocket.TestWebSocket.NIO.txt The fairly frequent (5%-10%) failure rate of TestCoyoteOutputStream still needs to be addressed. Apologies for the disruption to the 7.0.x release cycle. The combination of APR/native and WebSocket was not as stable as it appeared to be. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528175 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/tomcat/util/net/AprEndpoint.java
Author: markt
Date: Tue Oct 1 18:42:37 2013
New Revision: 1528175
URL: http://svn.apache.org/r1528175
Log:
If there are sockets to close, close them rather than waiting for the next
Poller run.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1528169
Modified: tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1528175&r1=1528174&r2=1528175&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Tue
Oct 1 18:42:37 2013
@@ -1623,7 +1623,7 @@ public class AprEndpoint extends Abstrac
}
// Check timeouts if the poller is empty
while (pollerRunning && connectionCount.get() < 1 &&
-addList.size() < 1) {
+addList.size() < 1 && closeList.size() < 1) {
// Reset maintain time.
try {
if (getSoTimeout() > 0 && pollerRunning) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528174 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/tomcat/util/net/AprEndpoint.java
Author: markt
Date: Tue Oct 1 18:41:43 2013
New Revision: 1528174
URL: http://svn.apache.org/r1528174
Log:
Ensure that connectionCount remains thread-safe
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1528166
Modified: tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1528174&r1=1528173&r2=1528174&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Tue
Oct 1 18:41:43 2013
@@ -27,6 +27,7 @@ import java.util.concurrent.ConcurrentHa
import java.util.concurrent.ConcurrentLinkedQueue;
import java.util.concurrent.Executor;
import java.util.concurrent.RejectedExecutionException;
+import java.util.concurrent.atomic.AtomicInteger;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
@@ -1307,10 +1308,17 @@ public class AprEndpoint extends Abstrac
/**
- * Amount of connections inside this poller.
+ * The number of connections currently inside this Poller. The correct
+ * operation of the Poller depends on this figure being correct. If it
+ * is not, it is possible that the Poller will enter a wait loop where
+ * it waits for the next connection to be added to the Poller before it
+ * calls poll when it should still be polling existing connections.
+ * Although not necessary at the time of writing this comment, it has
+ * been implemented as an AtomicInteger to ensure that it remains
+ * thread-safe.
*/
-protected int connectionCount = 0;
-public int getConnectionCount() { return connectionCount; }
+private AtomicInteger connectionCount = new AtomicInteger(0);
+public int getConnectionCount() { return connectionCount.get(); }
private volatile boolean pollerRunning = true;
@@ -1366,7 +1374,7 @@ public class AprEndpoint extends Abstrac
}
desc = new long[actualPollerSize * 2];
-connectionCount = 0;
+connectionCount.set(0);
addList = new SocketList(defaultPollerSize);
closeList = new SocketList(defaultPollerSize);
}
@@ -1425,7 +1433,7 @@ public class AprEndpoint extends Abstrac
}
}
Pool.destroy(pool);
-connectionCount = 0;
+connectionCount.set(0);
}
@@ -1498,7 +1506,7 @@ public class AprEndpoint extends Abstrac
rv = Poll.add(pollers[i], socket, events);
if (rv == Status.APR_SUCCESS) {
pollerSpace[i]--;
-connectionCount++;
+connectionCount.incrementAndGet();
return true;
}
}
@@ -1532,7 +1540,7 @@ public class AprEndpoint extends Abstrac
rv = Poll.remove(pollers[i], socket);
if (rv != Status.APR_NOTFOUND) {
pollerSpace[i]++;
-connectionCount--;
+connectionCount.decrementAndGet();
break;
}
}
@@ -1614,7 +1622,7 @@ public class AprEndpoint extends Abstrac
}
}
// Check timeouts if the poller is empty
-while (pollerRunning && connectionCount < 1 &&
+while (pollerRunning && connectionCount.get() < 1 &&
addList.size() < 1) {
// Reset maintain time.
try {
@@ -1731,7 +1739,7 @@ public class AprEndpoint extends Abstrac
}
if (rv > 0) {
pollerSpace[i] += rv;
-connectionCount -= rv;
+connectionCount.addAndGet(-rv);
for (int n = 0; n < rv; n++) {
timeouts.remove(desc[n*2+1]);
AprSocketWrapper wrapper = connections.get(
@@ -1830,7 +1838,7 @@ public class AprEndpoint extends Abstrac
long newPoller = allocatePoller(actualPollerSize,
pool, -1);
// Don't restore connections for now, since I have
not tested it
pollerSpace[i] = actualPollerSize;
-connectionCount -= count;
+connectionCount.addAndGet(-c
svn commit: r1528176 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/tomcat/util/net/AprEndpoint.java
Author: markt
Date: Tue Oct 1 18:43:04 2013
New Revision: 1528176
URL: http://svn.apache.org/r1528176
Log:
Address issue reported with high CPU usage under low load load.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1528171
Modified: tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1528176&r1=1528175&r2=1528176&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Tue
Oct 1 18:43:04 2013
@@ -1274,6 +1274,13 @@ public class AprEndpoint extends Abstrac
protected int pollerTime;
/**
+ * Variable poller timeout that adjusts depending on how many poll sets
+ * are in use so that the total poll time across all poll sets remains
+ * equal to pollTime.
+ */
+private int nextPollerTime;
+
+/**
* Root pool.
*/
protected long pool = 0;
@@ -1361,6 +1368,7 @@ public class AprEndpoint extends Abstrac
pollerCount = defaultPollerSize / actualPollerSize;
pollerTime = pollTime / pollerCount;
+nextPollerTime = pollerTime;
pollers = new long[pollerCount];
pollers[0] = pollset;
@@ -1735,7 +1743,18 @@ public class AprEndpoint extends Abstrac
int rv = 0;
// Iterate on each pollers, but no need to poll empty
pollers
if (pollerSpace[i] < actualPollerSize) {
-rv = Poll.poll(pollers[i], pollerTime, desc, true);
+rv = Poll.poll(pollers[i], nextPollerTime, desc,
true);
+// Reset the nextPollerTime
+nextPollerTime = pollerTime;
+} else {
+// Skipping an empty poll set means skipping a wait
+// time of pollerTime microseconds. If most of the
+// poll sets are skipped then this loop will be
+// tighter than expected which could lead to higher
+// than expected CPU usage. Extending the
+// nextPollerTime ensures that this loop always
+// takes about the same time to execute.
+nextPollerTime += pollerTime;
}
if (rv > 0) {
pollerSpace[i] += rv;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528177 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/tomcat/util/net/AprEndpoint.java java/org/apache/tomcat/util/net/res/LocalStrings.properties
Author: markt
Date: Tue Oct 1 18:43:32 2013
New Revision: 1528177
URL: http://svn.apache.org/r1528177
Log:
More debug logging for the APR/native connector.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1528172
Modified: tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1528177&r1=1528176&r2=1528177&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Tue
Oct 1 18:43:32 2013
@@ -1542,6 +1542,10 @@ public class AprEndpoint extends Abstrac
* {@link Poller#run()}.
*/
private boolean removeFromPoller(long socket) {
+if (log.isDebugEnabled()) {
+log.debug(sm.getString("endpoint.debug.pollerRemove",
+Long.valueOf(socket)));
+}
int rv = -1;
for (int i = 0; i < pollers.length; i++) {
if (pollerSpace[i] < actualPollerSize) {
@@ -1549,6 +1553,10 @@ public class AprEndpoint extends Abstrac
if (rv != Status.APR_NOTFOUND) {
pollerSpace[i]++;
connectionCount.decrementAndGet();
+if (log.isDebugEnabled()) {
+
log.debug(sm.getString("endpoint.debug.pollerRemoved",
+Long.valueOf(socket)));
+}
break;
}
}
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties?rev=1528177&r1=1528176&r2=1528177&view=diff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
(original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/res/LocalStrings.properties
Tue Oct 1 18:43:32 2013
@@ -28,6 +28,8 @@ endpoint.debug.destroySocket=Destroying
endpoint.debug.pollerAdd=Add to addList socket [{0}], timeout [{1}], flags
[{2}]
endpoint.debug.pollerAddDo=Add to poller socket [{0}]
endpoint.debug.pollerProcess=Processing socket [{0}] for event(s) [{1}]
+endpoint.debug.pollerRemove=Attempting to remove [{0}] from poller
+endpoint.debug.pollerRemoved=Removed [{0}] from poller
endpoint.debug.socket=socket [{0}]
endpoint.debug.socketCloseFail=Failed to close socket
endpoint.debug.socketTimeout=Timing out [{0}]
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528178 - /tomcat/trunk/webapps/examples/jsp/jsptoserv/jts.html
Author: kpreisser
Date: Tue Oct 1 18:46:55 2013
New Revision: 1528178
URL: http://svn.apache.org/r1528178
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55383
Improve markup of HTML page.
Fix broken link to "ServletToJsp.java.html" - it is generated by Ant txt2html
task.
Modified:
tomcat/trunk/webapps/examples/jsp/jsptoserv/jts.html
Modified: tomcat/trunk/webapps/examples/jsp/jsptoserv/jts.html
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/jsp/jsptoserv/jts.html?rev=1528178&r1=1528177&r2=1528178&view=diff
==
--- tomcat/trunk/webapps/examples/jsp/jsptoserv/jts.html (original)
+++ tomcat/trunk/webapps/examples/jsp/jsptoserv/jts.html Tue Oct 1 18:46:55
2013
@@ -1,4 +1,4 @@
-
+
-
+
+
Untitled Document
-
+
+img { border: 0; }
+
-
-
+
+
Execute
+ Return
-Source Code for JSP calling servlet
-
+Source Code for
JSP calling servlet
-Source Code for Servlet calling JSP
-
+Source Code for
Servlet calling JSP
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Broken links
On 26.9.2013 15:00, Konstantin Preißer wrote: > When looking at 3) and browsing in SVN history, it seems there never was such > a HTML > page that contains the source for servletToJsp.java. However, as I'm working > on improving > the HTML markup, I'm looking if we can get rid of those static HTML pages > that duplicate the > source code of other files (with adding syntax highlighting using legacy > elements > etc.), and use a programmatic solution to generate source code with syntax > highlighting instead. Sorry - I realized that those source files were generated by Ant's txt2html task which converts text files into HTML. The problem was that jts.html links to "servletToJsp.java.html" whereas the correct filename would be "ServletToJsp.java.html". I fixed the link in jts.html. Regards, Konstantin Preißer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528211 - /tomcat/trunk/java/org/apache/tomcat/buildutil/Txt2Html.java
Author: kpreisser
Date: Tue Oct 1 20:26:55 2013
New Revision: 1528211
URL: http://svn.apache.org/r1528211
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55383
- Improve HTML markup of generated pages by Txt2HTML ant task.
- Use declared encoding ("ISO-8859-1") instead of default encoding to read the
source files.
- Use declared line separator instead of "line.separator" property so that the
file is generated the same on every plattform.
Modified:
tomcat/trunk/java/org/apache/tomcat/buildutil/Txt2Html.java
Modified: tomcat/trunk/java/org/apache/tomcat/buildutil/Txt2Html.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/buildutil/Txt2Html.java?rev=1528211&r1=1528210&r2=1528211&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/buildutil/Txt2Html.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/buildutil/Txt2Html.java Tue Oct 1
20:26:55 2013
@@ -19,9 +19,11 @@ package org.apache.tomcat.buildutil;
import java.io.BufferedReader;
import java.io.File;
-import java.io.FileReader;
-import java.io.FileWriter;
+import java.io.FileInputStream;
+import java.io.FileOutputStream;
import java.io.IOException;
+import java.io.InputStreamReader;
+import java.io.OutputStreamWriter;
import java.io.PrintWriter;
import java.util.Iterator;
import java.util.LinkedList;
@@ -53,6 +55,18 @@ public class Txt2Html
private final List filesets = new LinkedList<>();
/**
+ * The encoding of the source files (.java and .jsp). Once they use
+ * UTF-8, this will need to be updated.
+ */
+private static final String SOURCE_ENCODING = "ISO-8859-1";
+
+/**
+ * Line terminator to be used for separating lines of the generated
+ * HTML page, to be independent from "line.separator" system property.
+ */
+private static final String LINE_SEPARATOR = "\r\n";
+
+/**
* Sets the directory to contain the resulting files
*
* @param todir The directory
@@ -126,39 +140,41 @@ public class Txt2Html
throws IOException
{
// Open files:
-BufferedReader in = new BufferedReader( new FileReader( from ) );
-PrintWriter out = new PrintWriter( new FileWriter( to ) );
+try (BufferedReader in = new BufferedReader(new InputStreamReader(
+new FileInputStream(from), SOURCE_ENCODING))) {
+try (PrintWriter out = new PrintWriter(new OutputStreamWriter(
+new FileOutputStream(to), "UTF-8"))) {
+
+// Output header:
+out.print(""
++ "Source Code" );
+
+// Convert, line-by-line:
+String line;
+while( (line = in.readLine()) != null ) {
+StringBuilder result = new StringBuilder();
+int len = line.length();
+for( int i = 0; i < len; i++ ) {
+char c = line.charAt( i );
+switch( c ) {
+case '&':
+result.append( "&" );
+break;
+case '<':
+result.append( "<" );
+break;
+default:
+result.append( c );
+}
+}
+out.print( result.toString() + LINE_SEPARATOR );
+}
-// Output header:
-out.println( "" );
+// Output footer:
+out.print( "" );
-// Convert, line-by-line:
-String line;
-while( (line = in.readLine()) != null ) {
-StringBuilder result = new StringBuilder();
-int len = line.length();
-for( int i = 0; i < len; i++ ) {
-char c = line.charAt( i );
-switch( c ) {
-case '&':
-result.append( "&" );
-break;
-case '<':
-result.append( "<" );
-break;
-default:
-result.append( c );
-}
}
-out.println( result.toString() );
}
-
-// Output footer:
-out.println( "" );
-
-// Close streams:
-out.close();
-in.close();
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528212 - /tomcat/tc7.0.x/trunk/webapps/examples/jsp/jsptoserv/jts.html
Author: kpreisser Date: Tue Oct 1 20:36:09 2013 New Revision: 1528212 URL: http://svn.apache.org/r1528212 Log: Fix broken link to "ServletToJsp.java.html" - it is generated by Ant txt2html task. Modified: tomcat/tc7.0.x/trunk/webapps/examples/jsp/jsptoserv/jts.html Modified: tomcat/tc7.0.x/trunk/webapps/examples/jsp/jsptoserv/jts.html URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/examples/jsp/jsptoserv/jts.html?rev=1528212&r1=1528211&r2=1528212&view=diff == --- tomcat/tc7.0.x/trunk/webapps/examples/jsp/jsptoserv/jts.html (original) +++ tomcat/tc7.0.x/trunk/webapps/examples/jsp/jsptoserv/jts.html Tue Oct 1 20:36:09 2013 @@ -27,7 +27,7 @@ Source Code for JSP calling servlet -Source Code for Servlet calling JSP +Source Code for Servlet calling JSP - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: 8.0.x / 7.0.x progress
Hi Mark, > -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Tuesday, October 1, 2013 8:39 PM > To: Tomcat Developers List > Subject: 8.0.x / 7.0.x progress > > Pulling together information from multiple threads: > > 8.0.x trunk appears to be stable (i.e. no longer crashes) but the > FormAuthenticator unit tests are very slow (24 minutes). This needs to > be resolved. I noticed something strange with the Snake WebSocket example when running current trunk (r1528211) on Windows (x64) with 64-bit version of tcnative-1.dll (version 1.1.29 - from Mladen: http://people.apache.org/~mturk/native/tomcat-native-win32-x86_64-r1528132.zip). If I open the snake.xhtml with Firefox and with Chrome, press the "up" key so that the snakes move, and then close Chrome, Tomcat does not seem to realize that the underlying TCP connection of the WebSocket connection has been closed, and the snake keeps running. However if I do this with IE 10 or Firefox (open snake.xhtml, press key, close the browser) then the corresponding snakes disappear. (Maybe Chrome does not send some "Close Websocket" message before closing/aborting the TCP connection.) When I do this a few times, then eventually when I open snake.xhtml in Chrome, it will only display "Info: WebSocket closed." (and no snakes are visible), and Tomcat prints following exceptions: 01-Oct-2013 23:16:00.340 SEVERE [http-apr-8080-exec-1] org.apache.tomcat.websocket.pojo.PojoEndpointBase.onError No error handling configured for [websocket.snake.SnakeAnnotation] and the following error occurred java.io.IOException: java.util.concurrent.ExecutionException: java.io.EOFException at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:226) at org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:474) at org.apache.tomcat.websocket.WsSession.onClose(WsSession.java:438) at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.close(WsHttpUpgradeHandler.java:172) at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.access$200(WsHttpUpgradeHandler.java:45) at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsReadListener.onDataAvailable(WsHttpUpgradeHandler.java:194) at org.apache.coyote.http11.upgrade.AbstractServletInputStream.onDataAvailable(AbstractServletInputStream.java:169) at org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDispatch(AbstractProcessor.java:95) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:638) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:282) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2399) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2388) 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:724) Caused by: java.util.concurrent.ExecutionException: java.io.EOFException at org.apache.tomcat.websocket.FutureToSendHandler.get(FutureToSendHandler.java:102) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:222) ... 14 more Caused by: java.io.EOFException at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doClose(WsRemoteEndpointImplServer.java:121) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.close(WsRemoteEndpointImplBase.java:536) at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:102) at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.doWrite(WsRemoteEndpointImplServer.java:71) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:358) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessage(WsRemoteEndpointImplBase.java:259) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:217) ... 14 more Rarely then I also get the following exception in SnakeTimer.broadcast(String message), but this is probably caused by a concurrency issue (e.g. if the timer starts to loop over the snakes to send some messages, but at the same time one of the websocket connections has been closed which is handled by another thread): 01-Oct-2013 23:16:00.346 SEVERE [SnakeTimer Timer] websocket.snake.SnakeTimer$1.run Caught to prevent timer from shutting down java.lang.IllegalStateException: Message will not be sent because the WebSocket session has been closed [...] If I try the same with the NIO connector, then the behavior is differe
svn commit: r1528248 - /tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Author: markt Date: Tue Oct 1 22:46:22 2013 New Revision: 1528248 URL: http://svn.apache.org/r1528248 Log: Ensure that the Poller actions socket close requests ASAP Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1528248&r1=1528247&r2=1528248&view=diff == --- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original) +++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Tue Oct 1 22:46:22 2013 @@ -1540,6 +1540,7 @@ public class AprEndpoint extends Abstrac return false; } closeList.add(socket, 0, 0); +this.notify(); return true; } } - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528250 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/tomcat/util/net/AprEndpoint.java
Author: markt Date: Tue Oct 1 22:48:15 2013 New Revision: 1528250 URL: http://svn.apache.org/r1528250 Log: Ensure that the Poller actions socket close requests ASAP Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Propchange: tomcat/tc7.0.x/trunk/ -- Merged /tomcat/trunk:r1528248 Modified: tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1528250&r1=1528249&r2=1528250&view=diff == --- tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original) +++ tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Tue Oct 1 22:48:15 2013 @@ -1532,6 +1532,7 @@ public class AprEndpoint extends Abstrac return false; } closeList.add(socket, 0, 0); +this.notify(); return true; } } - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1528258 - /tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Author: markt
Date: Tue Oct 1 22:59:31 2013
New Revision: 1528258
URL: http://svn.apache.org/r1528258
Log:
Async timeouts are checked roughly once a second. Check connection and
keep-alive timeouts using the same period (rather than roughly every 5s)
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1528258&r1=1528257&r2=1528258&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Tue Oct 1
22:59:31 2013
@@ -1580,9 +1580,9 @@ public class AprEndpoint extends Abstrac
private void maintain() {
long date = System.currentTimeMillis();
-// Maintain runs at most once every 5s, although it will likely get
+// Maintain runs at most once every 1s, although it will likely get
// called more
-if ((date - lastMaintain) < 5000L) {
+if ((date - lastMaintain) < 1000L) {
return;
} else {
lastMaintain = date;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55608] fmt:bundle tag unnecessarily buffers body content
https://issues.apache.org/bugzilla/show_bug.cgi?id=55608 --- Comment #4 from Dan Armstrong --- (In reply to Christopher Schultz from comment #3) > One could argue that might actually be used to intentionally > buffer content a bit, just in case an error occurs. Once the response is > committed, errors occurring during rendering are usually catastrophic to the > page display. > > How about making this a "JSP property" that is disabled by default (i.e. the > current behavior is the default, but easily changed)? One can argue anything, but that doesn't make it a valid argument. This is precisely what the buffer page attribute is for. fmt:bundle implemented with an unbounded buffer is not "buffering a little". For example: <%@ page language="java" buffer="512kb" autoFlush="true" pageEncoding="UTF-8" session="false" %> -- 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 55608] fmt:bundle tag unnecessarily buffers body content
https://issues.apache.org/bugzilla/show_bug.cgi?id=55608 --- Comment #5 from Dan Armstrong --- Created attachment 30899 --> https://issues.apache.org/bugzilla/attachment.cgi?id=30899&action=edit Diff for changes to current trunk of BundleSupport.java I have attached a diff for the current trunk version. Changed doStartTag to return EVAL_BODY_INCLUDE. Removed doEndTag method entirely. -- 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 55608] fmt:bundle tag unnecessarily buffers body content
https://issues.apache.org/bugzilla/show_bug.cgi?id=55608 --- Comment #6 from Christopher Schultz --- (In reply to Dan Armstrong from comment #4) > (In reply to Christopher Schultz from comment #3) > > One could argue that might actually be used to intentionally > > buffer content a bit, just in case an error occurs. Once the response is > > committed, errors occurring during rendering are usually catastrophic to the > > page display. > > > > How about making this a "JSP property" that is disabled by default (i.e. the > > current behavior is the default, but easily changed)? > > One can argue anything, but that doesn't make it a valid argument. It's a fairly valid argument that changing the way a component behaves can inconvenience a lot of people. Hence my suggestion that it be made into a configurable setting, defaulting to the old behavior. Jeremy may apply your patch, but I certainly wouldn't. -- 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 55608] fmt:bundle tag unnecessarily buffers body content
https://issues.apache.org/bugzilla/show_bug.cgi?id=55608 --- Comment #7 from Kris Schneider --- I don't think the page directive and its attributes really have any bearing on this, but since I generally agree with the changes, it's probably not worth going into. The JSTL 1.1 & 1.2 specs have this to say about the body content: JSP. The JSP container processes the body content and then writes it to the current JspWriter. The action ignores the body content. The last sentence is the key and I'd claim that it actually makes more sense for BundleSupport to extend TagSupport instead of BodyTagSupport. -- 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 55608] fmt:bundle tag unnecessarily buffers body content
https://issues.apache.org/bugzilla/show_bug.cgi?id=55608 --- Comment #8 from Dan Armstrong --- Agreed that changing component behavior, even if the change is inline with the spec, can be problematic. Especially within a minor release in series like 1.1.2 -> 1.1.3. Consider Oracle changing Java string implementation dramatically in 1.7.0_06 as a prime example of the problems this can cause. I hope this change will make it into the 1.2 branch still under development. If there are release notes this is a good one to add to the list. Developers can understand a change during a 1.1 -> 1.2 upgrade as long as it is documented. I agree that this tag could extend TagSupport as well and achieve the same behavior. +1 for basing the decision off the specification. Thank you very much for your help. - Dan -- 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: Recent tcnative null-dereference with 8.0.0-RC3 and 7.0.45 [tcnative-1.dll+0x7e23]
On 10/01/2013 07:32 PM, sebb wrote: If a Java application succeeds in crashing the JVM, then IMO the JVM has a bug. I believe that all native code should strive to behave the same way. This is conceptual difference. Most of those checks are done again inside Java. However inside JVM the Java API hides its native methods and ensures params are validated. Our API is Servlet spec and our VM is Tomcat. All the invalid data should be checked in java part which can be invalid as part of normal operation. Our native code already checks for some invalid data which can be invalid in such situations. OTOH invalid data passed to native caused by bug is just that, a bug. So fix the bug and you won't need the check. We can add compile time '#if defined(MAINTAINER_MODE) ... #endif' checks for easier debugging at development, but all the checks inside native method can be equally well coded before the actual JNI call and since our API is servlet and no use code can pass beyond that. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
