[Bug 63767] install windows service, tomcat9 start crash.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63767 --- Comment #8 from 王化亮 <6900...@qq.com> --- thank you very much! -- 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
buildbot success in on tomcat-trunk
The Buildbot has detected a restored build on builder tomcat-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-trunk/builds/4630 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' triggered this build Build Source Stamp: [branch master] bfff085526f4c3625316be311ca5b3dee41d83b3 Blamelist: Mark Thomas Build succeeded! Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Fix test failures with APR/native.
On 25/09/2019 21:39, ma...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> markt pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new bfff085 Fix test failures with APR/native.
> bfff085 is described below
My ideas with the blocking status locks didn't work as well as I hoped.
I could only fix the error if shutdown waited for all in-progress
blocking reads to complete or timeout. Given there are some WebSocket
scenarios that have very long blocking reads that didnlt seem like a
good idea.
I think the best thing to do is aim to minimise the chances of this
crash as much as practical. Given the tentative plan to remove native
I/O in Tomcat 10 I don't think it is worth spending time on the
significant refactoring that would be required for a more reliable solution.
Mark
>
> commit bfff085526f4c3625316be311ca5b3dee41d83b3
> Author: Mark Thomas
> AuthorDate: Wed Sep 25 21:39:30 2019 +0100
>
> Fix test failures with APR/native.
> ---
> test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
> a/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
> b/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
> index 86e574e..a3a22d9 100644
> --- a/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
> +++ b/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
> @@ -404,6 +404,7 @@ public class TestChunkedInputFilter extends
> TomcatBaseTest {
> client.connect();
> try {
> client.processRequest();
> +client.disconnect();
> } catch (Exception e) {
> // Socket was probably closed before client had a chance to read
> // response
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@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
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #23 from Boris Petrov --- Well, I'm not sure what exactly you mean, but if you need more stacktraces, here you go: ``` javax.ws.rs.ProcessingException: Failed to buffer the message content input stream. at org.glassfish.jersey.message.internal.InboundMessageContext.bufferEntity(InboundMessageContext.java:907) ... user code Caused by: org.apache.catalina.connector.ClientAbortException: java.io.IOException: Stream reset at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:340) at org.apache.catalina.connector.InputBuffer.checkByteBufferEof(InputBuffer.java:632) at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:362) at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:132) at java.base/java.io.FilterInputStream.read(FilterInputStream.java:133) at java.base/java.io.PushbackInputStream.read(PushbackInputStream.java:183) at java.base/java.io.FilterInputStream.read(FilterInputStream.java:107) at org.glassfish.jersey.message.internal.ReaderWriter.writeTo(ReaderWriter.java:92) at org.glassfish.jersey.message.internal.InboundMessageContext.bufferEntity(InboundMessageContext.java:894) ... 52 common frames omitted Caused by: java.io.IOException: Stream reset at org.apache.coyote.http2.Stream$StreamInputBuffer.doRead(Stream.java:1084) at org.apache.coyote.Request.doRead(Request.java:551) at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:336) ... 60 common frames omitted ``` And this one: ``` javax.ws.rs.ProcessingException: Failed to buffer the message content input stream. at org.glassfish.jersey.message.internal.InboundMessageContext.bufferEntity(InboundMessageContext.java:907) ... user code Caused by: org.apache.catalina.connector.ClientAbortException: java.io.IOException: The socket [140,630,383,004,352] associated with this connection has been closed. at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:340) at org.apache.catalina.connector.InputBuffer.checkByteBufferEof(InputBuffer.java:632) at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:362) at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:132) at java.base/java.io.FilterInputStream.read(FilterInputStream.java:133) at java.base/java.io.PushbackInputStream.read(PushbackInputStream.java:183) at java.base/java.io.FilterInputStream.read(FilterInputStream.java:107) at org.glassfish.jersey.message.internal.ReaderWriter.writeTo(ReaderWriter.java:92) at org.glassfish.jersey.message.internal.InboundMessageContext.bufferEntity(InboundMessageContext.java:894) ... 52 common frames omitted Caused by: java.io.IOException: The socket [140,630,383,004,352] associated with this connection has been closed. at org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper.doWrite(AprEndpoint.java:2315) at org.apache.tomcat.util.net.SocketWrapperBase.doWrite(SocketWrapperBase.java:793) at org.apache.tomcat.util.net.SocketWrapperBase.writeBlocking(SocketWrapperBase.java:529) at org.apache.tomcat.util.net.SocketWrapperBase.write(SocketWrapperBase.java:454) at org.apache.coyote.http2.Http2UpgradeHandler.writeWindowUpdate(Http2UpgradeHandler.java:808) at org.apache.coyote.http2.Stream$StreamInputBuffer.doRead(Stream.java:1127) at org.apache.coyote.Request.doRead(Request.java:551) at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:336) ... 60 common frames omitted ``` Please tell me if you need more information or if you think this is "normal" and there is some issue in my configuration/setup. -- 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] branch 7.0.x updated: Fix test failures with APR/native.
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/7.0.x by this push:
new 3ad2262 Fix test failures with APR/native.
3ad2262 is described below
commit 3ad22622d1758fee5168f7630e537e1f937a522f
Author: Mark Thomas
AuthorDate: Wed Sep 25 21:39:30 2019 +0100
Fix test failures with APR/native.
---
test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java | 1 +
1 file changed, 1 insertion(+)
diff --git a/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
b/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
index 6a656c0..507b5d6 100644
--- a/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
+++ b/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
@@ -404,6 +404,7 @@ public class TestChunkedInputFilter extends TomcatBaseTest {
client.connect();
try {
client.processRequest();
+client.disconnect();
} catch (Exception e) {
// Socket was probably closed before client had a chance to read
// response
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch master updated: Fix test failures with APR/native.
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new bfff085 Fix test failures with APR/native.
bfff085 is described below
commit bfff085526f4c3625316be311ca5b3dee41d83b3
Author: Mark Thomas
AuthorDate: Wed Sep 25 21:39:30 2019 +0100
Fix test failures with APR/native.
---
test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java | 1 +
1 file changed, 1 insertion(+)
diff --git a/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
b/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
index 86e574e..a3a22d9 100644
--- a/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
+++ b/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
@@ -404,6 +404,7 @@ public class TestChunkedInputFilter extends TomcatBaseTest {
client.connect();
try {
client.processRequest();
+client.disconnect();
} catch (Exception e) {
// Socket was probably closed before client had a chance to read
// response
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 8.5.x updated: Fix test failures with APR/native.
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/8.5.x by this push:
new 3aba970 Fix test failures with APR/native.
3aba970 is described below
commit 3aba970811c804348091b0555f5b7d8718fd356f
Author: Mark Thomas
AuthorDate: Wed Sep 25 21:39:30 2019 +0100
Fix test failures with APR/native.
---
test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java | 1 +
1 file changed, 1 insertion(+)
diff --git a/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
b/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
index 503e1cd..972cf6e 100644
--- a/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
+++ b/test/org/apache/coyote/http11/filters/TestChunkedInputFilter.java
@@ -403,6 +403,7 @@ public class TestChunkedInputFilter extends TomcatBaseTest {
client.connect();
try {
client.processRequest();
+client.disconnect();
} catch (Exception e) {
// Socket was probably closed before client had a chance to read
// response
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #22 from Mark Thomas --- 9.0.26 will handle the behaviour in the original trace. That doesn't mean there isn't more "unusual" behaviour that will trigger the 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
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #21 from Boris Petrov --- Thanks for the tip, Mark. I'll try that tomorrow. But... is this setting still needed? I thought that Tomcat 9.0.26 would remove the need for custom configuration and would work out-of-the-box with Chrome settings/bugs? Or you're waiting for them to be resolved? -- 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: [Bug 61441] daemon.sh's auto-detection fails on linux system's where java is installed via an RPM
Am 19.09.19 um 10:02 schrieb Mark Thomas: > On 19/09/2019 08:07, Felix Schumacher wrote: >> That is obviously spam. > When discussing spam please don't quote the material - particularly any > links - as getting the links published as many times as possible is the > aim of the spam. Will try to remember it. > >> My question here is, what is the official way to >> get rid of such entries? > Officially, the process is email bugzilla-admin@a.o and ask them to: > - disable the account > - delete the spam comment > > Since that email lands in my inbox I tend to skip the sending the email > bit ;) > > If you want to help out - help is always appreciated - I can give you > the BZ karma necessary to disable accounts. You usually need to do a > little poking around to see if they have created any other comments as > they tend to spread them over several projects. > > Deleting the comments requires executing SQL directly on the database. That sounds almost like fun. I can try to help. Felix > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@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
buildbot failure in on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-trunk/builds/4629 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' triggered this build Build Source Stamp: [branch master] 17890c3d2696bc634129f746901d7edb3b4dc8aa Blamelist: Mark Thomas BUILD FAILED: failed compile_1 Sincerely, -The Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch master updated: Refacfor to (hopefully) aid fixing crash on shutdown
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new 17890c3 Refacfor to (hopefully) aid fixing crash on shutdown
17890c3 is described below
commit 17890c3d2696bc634129f746901d7edb3b4dc8aa
Author: Mark Thomas
AuthorDate: Wed Sep 25 16:33:25 2019 +0100
Refacfor to (hopefully) aid fixing crash on shutdown
Reduce code duplication slightly. Check closed status inside each lock
so a) check is closer to the code that uses the socket and b) we have
the option of using the lock to help avoid the crash
---
java/org/apache/tomcat/util/net/AprEndpoint.java | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/java/org/apache/tomcat/util/net/AprEndpoint.java
b/java/org/apache/tomcat/util/net/AprEndpoint.java
index 46c7047..bd7149d 100644
--- a/java/org/apache/tomcat/util/net/AprEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AprEndpoint.java
@@ -2138,10 +2138,6 @@ public class AprEndpoint extends
AbstractEndpoint implements SNICallB
private int fillReadBuffer(boolean block, ByteBuffer to) throws
IOException {
-if (isClosed()) {
-throw new IOException(sm.getString("socket.apr.closed",
getSocket()));
-}
-
Lock readLock = getBlockingStatusReadLock();
WriteLock writeLock = getBlockingStatusWriteLock();
@@ -2149,6 +2145,7 @@ public class AprEndpoint extends
AbstractEndpoint implements SNICallB
int result = 0;
readLock.lock();
try {
+checkClosed();
if (getBlockingStatus() == block) {
if (block) {
Socket.timeoutSet(getSocket().longValue(),
getReadTimeout() * 1000);
@@ -2164,6 +2161,7 @@ public class AprEndpoint extends
AbstractEndpoint implements SNICallB
if (!readDone) {
writeLock.lock();
try {
+checkClosed();
// Set the current settings for this socket
setBlockingStatus(block);
if (block) {
@@ -2234,6 +2232,13 @@ public class AprEndpoint extends
AbstractEndpoint implements SNICallB
}
+private void checkClosed() throws IOException {
+if (isClosed()) {
+throw new IOException(sm.getString("socket.apr.closed",
getSocket()));
+}
+}
+
+
@Override
protected void doClose() {
if (log.isDebugEnabled()) {
@@ -2311,15 +2316,12 @@ public class AprEndpoint extends
AbstractEndpoint implements SNICallB
@Override
protected void doWrite(boolean block, ByteBuffer from) throws
IOException {
-if (isClosed()) {
-throw new IOException(sm.getString("socket.apr.closed",
getSocket()));
-}
-
Lock readLock = getBlockingStatusReadLock();
WriteLock writeLock = getBlockingStatusWriteLock();
readLock.lock();
try {
+checkClosed();
if (getBlockingStatus() == block) {
if (block) {
Socket.timeoutSet(getSocket().longValue(),
getWriteTimeout() * 1000);
@@ -2333,6 +2335,7 @@ public class AprEndpoint extends
AbstractEndpoint implements SNICallB
writeLock.lock();
try {
+checkClosed();
// Set the current settings for this socket
setBlockingStatus(block);
if (block) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #20 from Mark Thomas --- 9.0.26 fixed a typo in the attribute name. You want overheadDataThreshold in 9.0.26 onwards. -- 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 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #19 from Boris Petrov --- Mark, I'm observing a similar behavior on 9.0.26. The socket is closed even when the `overheadDataThreadhold="0"` setting is set. Browser is Chromium 77.0.3865.90. I had to revert to 9.0.24 with that setting in order to make it work. Should I open a new issue or reopen this one perhaps? -- 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 63767] install windows service, tomcat9 start crash.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63767 --- Comment #7 from Mark Thomas --- Already reported against Commons Daemon as https://issues.apache.org/jira/browse/DAEMON-408 -- 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 63767] install windows service, tomcat9 start crash.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63767 --- Comment #6 from Mark Thomas --- Found it. A good demonstration of my lack of C coding skills. I failed to initialise a variable so it was non-NULL when I expected it to be NULL causing Commons Daemon to try and call a function that didn't exist. Hence the crash. I have a fix which I have tested locally. I'll get the fix applied to Commons Daemon start the release process. Hopefully we'll be able to pick up the fix in the next round of Tomcat releases. -- 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: Performance bottleneck in WebappClassLoaderBase
This is a question, to start with at least, for the users mailing list. Mark On 25/09/2019 11:46, Gunnar Brand wrote: > Hello. > > > > Recently we received complaints from a customer about slow response > times (45 seconds) every morning. Every morning starting a fresh session > in the browser would require a long wait time for the first user, but > once this hurdle had been taken everything seemed to work fine. > > We could reproduce this in house, and doing a thread dump during this > time span showed the class loader trying to open a jar file. Immediately > we suspected a virus scanner slowing access to jar files (and since > signatures are updated daily, this happened daily). Blocking the virus > scanner from the tomcat folder helped but this is just alleviating the > symptoms, not the cure. Doing a full trace log of the class loader > package showed the problem: > > For any unknown resource or class the class loader seems to populate all > known jars, and either finds it, then loads it, and keeps a cache entry > (with the class for classes), or if it can’t find it, asks the parent > class loader (this is the spec order of things). > > The log was filled classes and resources that couldn’t be found and were > delegated to the parent. Over and over again. Each and every one of > theses requests scans all jar files. Clear the OS cache and the problem > appears, too. > > > > For classes one would believe this cannot be, once a class is loaded, > it’s loaded. But with dynamic script languages, they often use > Class.forName() and for example Rhino even does that for packages (that > might not even exist!). > > We fixed at least Rhino with an application wide global top level , so > for classes this problem did go away (there might be other, unless they > implement their own caching, there is a risk). > > Resources are still a problem, our log is filled with > > 24-Sep-2019 17:22:55.482 FINE [http-nio-8080-exec-6] > org.apache.catalina.loader.WebappClassLoaderBase.findResources > findResources(META-INF/services/javax.xml.parsers.DocumentBuilderFactory) > > 24-Sep-2019 17:22:55.484 FINE [http-nio-8080-exec-6] > org.apache.catalina.loader.WebappClassLoaderBase.getResourceAsStream > getResourceAsStream(META-INF/services/org.apache.xerces.xni.parser.XMLParserConfiguration) > > 24-Sep-2019 17:22:55.484 FINE [http-nio-8080-exec-6] > org.apache.catalina.loader.WebappClassLoaderBase.getResourceAsStream > Searching local repositories > > 24-Sep-2019 17:22:55.485 FINE [http-nio-8080-exec-6] > org.apache.catalina.loader.WebappClassLoaderBase.getResourceAsStream > Delegating to parent classloader unconditionally > java.net.URLClassLoader@578486a3 > > 24-Sep-2019 17:22:55.485 FINE [http-nio-8080-exec-6] > org.apache.catalina.loader.WebappClassLoaderBase.getResourceAsStream > --> Resource not found, returning null > > If there is only a single repeated “Searching local repositories” for a > certain URL, the problem is there (doesn’t matter if the resource or > class exists or not). > > > > It’s obviously a bad idea to scan the filesystem or jars every time. > > The WebappClassLoaderBase keeps information about every resource and > class it finds, so repeated calls for these do not cost that much time, > especially for classes that are stored in the cache. > > I believe it might work to keep a negative entry for classes it doesn’t > find but the parent class loader knows and immediately ask the parent > class loader. Maybe also for resources. But I don’t know what is > supposed to happen if somebody overwrites a resource (or class) later. > > Even worse if the class/resource does not exist yet. Maybe populating > the whole resource tree in memory is the only solution (with background > update?!) . > > > > I mainly wanted to raise awareness of this problem, I am not well versed > with class loading, so I can’t really help there. > > > > Sincerely, > > Gunnar Brand > > > > > > > > Gunnar Brand | Softwareentwickler > > interface projects GmbH | www.intergator.de > > Zwinglistraße 11/13 | 01277 Dresden | Deutschland > > Tel: +49-351-31809-41 | Fax: +49-351-31809-33 > > > > Folgen Sie intergator auf: > > Twitter : https://twitter.com/intergator > > xing : https://www.xing.com/companies/interfaceprojectsgmbh > > LinkedIn: http://www.linkedin.com/company/interface-projects-gmbh > > YouTube : http://www.youtube.com/user/TheEnterpriseSearch?feature=watch > > Facebook: https://www.facebook.com/intergator/ > > RSS : https://www.intergator.de/feed/ > > > > Geschäftsführer: Dr. Uwe Crenze, Eduard Daoud > > Amtsgericht Dresden HRB 8740 > > > > Haftungsausschluss / Disclaimer > > http://www.intergator.de/email-disclaimer.shtml > > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Performance bottleneck in WebappClassLoaderBase
Hello. Recently we received complaints from a customer about slow response times (45 seconds) every morning. Every morning starting a fresh session in the browser would require a long wait time for the first user, but once this hurdle had been taken everything seemed to work fine. We could reproduce this in house, and doing a thread dump during this time span showed the class loader trying to open a jar file. Immediately we suspected a virus scanner slowing access to jar files (and since signatures are updated daily, this happened daily). Blocking the virus scanner from the tomcat folder helped but this is just alleviating the symptoms, not the cure. Doing a full trace log of the class loader package showed the problem: For any unknown resource or class the class loader seems to populate all known jars, and either finds it, then loads it, and keeps a cache entry (with the class for classes), or if it can’t find it, asks the parent class loader (this is the spec order of things). The log was filled classes and resources that couldn’t be found and were delegated to the parent. Over and over again. Each and every one of theses requests scans all jar files. Clear the OS cache and the problem appears, too. For classes one would believe this cannot be, once a class is loaded, it’s loaded. But with dynamic script languages, they often use Class.forName() and for example Rhino even does that for packages (that might not even exist!). We fixed at least Rhino with an application wide global top level , so for classes this problem did go away (there might be other, unless they implement their own caching, there is a risk). Resources are still a problem, our log is filled with 24-Sep-2019 17:22:55.482 FINE [http-nio-8080-exec-6] org.apache.catalina.loader.WebappClassLoaderBase.findResources findResources(META-INF/services/javax.xml.parsers.DocumentBuilderFactory) 24-Sep-2019 17:22:55.484 FINE [http-nio-8080-exec-6] org.apache.catalina.loader.WebappClassLoaderBase.getResourceAsStream getResourceAsStream(META-INF/services/org.apache.xerces.xni.parser.XMLParserConfiguration) 24-Sep-2019 17:22:55.484 FINE [http-nio-8080-exec-6] org.apache.catalina.loader.WebappClassLoaderBase.getResourceAsStream Searching local repositories 24-Sep-2019 17:22:55.485 FINE [http-nio-8080-exec-6] org.apache.catalina.loader.WebappClassLoaderBase.getResourceAsStream Delegating to parent classloader unconditionally java.net.URLClassLoader@578486a3 24-Sep-2019 17:22:55.485 FINE [http-nio-8080-exec-6] org.apache.catalina.loader.WebappClassLoaderBase.getResourceAsStream --> Resource not found, returning null If there is only a single repeated “Searching local repositories” for a certain URL, the problem is there (doesn’t matter if the resource or class exists or not). It’s obviously a bad idea to scan the filesystem or jars every time. The WebappClassLoaderBase keeps information about every resource and class it finds, so repeated calls for these do not cost that much time, especially for classes that are stored in the cache. I believe it might work to keep a negative entry for classes it doesn’t find but the parent class loader knows and immediately ask the parent class loader. Maybe also for resources. But I don’t know what is supposed to happen if somebody overwrites a resource (or class) later. Even worse if the class/resource does not exist yet. Maybe populating the whole resource tree in memory is the only solution (with background update?!) . I mainly wanted to raise awareness of this problem, I am not well versed with class loading, so I can’t really help there. Sincerely, Gunnar Brand Gunnar Brand | Softwareentwickler interface projects GmbH | www.intergator.de Zwinglistraße 11/13 | 01277 Dresden | Deutschland Tel: +49-351-31809-41 | Fax: +49-351-31809-33 Folgen Sie intergator auf: Twitter : https://twitter.com/intergator xing: https://www.xing.com/companies/interfaceprojectsgmbh LinkedIn: http://www.linkedin.com/company/interface-projects-gmbh YouTube : http://www.youtube.com/user/TheEnterpriseSearch?feature=watch Facebook: https://www.facebook.com/intergator/ RSS : https://www.intergator.de/feed/ Geschäftsführer: Dr. Uwe Crenze, Eduard Daoud Amtsgericht Dresden HRB 8740 Haftungsausschluss / Disclaimer http://www.intergator.de/email-disclaimer.shtml
[Bug 63767] install windows service, tomcat9 start crash.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63767 --- Comment #5 from Mark Thomas --- Installed Windows Update Agent 7.8.9200.16924 - no change. Installed 2019-09 Preview of Monthly Quality Rollup for Windows Server 2012 for x64-based Systems (KB4516069) - problem resolved. This does indeed look like an issue with a missing update. Generally, Commons Daemon (and Tomcat) work on the basis that they are supported if all current updates have been applied. On that basis this looks like an issue with the server. That said, I'd like to dig into why this is happening as there may be scope to work-around the missing update in the Commons Daemon code. -- 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 63767] install windows service, tomcat9 start crash.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63767 --- Comment #4 from Mark Thomas --- I have been able to re-create this. Here are a few more details for the record en_windows_server_2012_vl_x64_dvd_917758.iso - via My Visual Studio - Standard install with GUI - UK locale - All other settings using defaults - Networking configured via DHCP Oracle jdk1.8_201 Windows 64-bit - default installation options Java_HOME set to: C:\Program Files\Java\jdk1.8.0_201 apache-tomcat-9.0.26-windows-x64.zip - extract to C:\ I'm currently running Windows update to see if the root cause is a missing 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
[Bug 63771] A way to strip 'Secure' From the cookie
https://bz.apache.org/bugzilla/show_bug.cgi?id=63771 Mark Thomas changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Mark Thomas --- This is a configuration question and belongs on the users mailing list. -- 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 63771] New: A way to strip 'Secure' From the cookie
https://bz.apache.org/bugzilla/show_bug.cgi?id=63771 Bug ID: 63771 Summary: A way to strip 'Secure' From the cookie Product: Tomcat 8 Version: 8.5.46 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: a...@gentoo.org Target Milestone: Hello, we have the following situations: nginx listen on port 80 and 443, and there is a proxy_pass to tomcat. Tomcat is not on the same machine so the traffic between nginx and tomcat is encrypted by using tomcat on ssl. We need to leave nginx listen on 80 because there are some embebbed devices that do not support SSL, so they will fail on 443. The issue, for us, is that if you try to connect to 80 with a browser, the 'set-cookie' header contains 'Secure' added by tomcat, so it will fail in plain text. We were able to fix the issue as described here: https://serverfault.com/questions/853228/nginx-reverse-proxy-remove-secure-from-cookies Would be great to have a feature to strip the 'Secure' object added to the header (unless I failed to search and already exists) Thanks in advance -- 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] branch master updated: fix comment
This is an automated email from the ASF dual-hosted git repository. kfujino pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/master by this push: new dd2faec fix comment dd2faec is described below commit dd2faecf717b852de31e33f69c6be2844fbaea78 Author: KeiichiFujino AuthorDate: Wed Sep 25 15:16:14 2019 +0900 fix comment --- java/org/apache/catalina/tribes/membership/StaticMembershipService.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/java/org/apache/catalina/tribes/membership/StaticMembershipService.java b/java/org/apache/catalina/tribes/membership/StaticMembershipService.java index d3d91a1..299b961 100644 --- a/java/org/apache/catalina/tribes/membership/StaticMembershipService.java +++ b/java/org/apache/catalina/tribes/membership/StaticMembershipService.java @@ -43,7 +43,7 @@ public class StaticMembershipService extends MembershipServiceBase private StaticMembershipProvider provider; /** - * the ObjectName of this McastService. + * the ObjectName of this MembershipService. */ private ObjectName oname = null; - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
