Re: Tomcat Auto Shutdown issues
Naveen, Can u provide the setenv changes and total system RAM and free RAM output for need to investigation Regards, Ramesh On Apr 29, 2017 8:53 PM, "Naveen Nandyala - Vendor" < naveen.nandy...@walmart.com> wrote: > Hi Team, > > We are using Tomcat "7.0.61.0", and running on SUSE Linux > Enterprise Server 11 (x86_64), Version 11, and PatchLevel 3. Our tomcat > instance is going down due to below message, and its not a normal shutdown > we are not sure why and who is causing to throw this messages and causing > tomcat instance go down. Can anyone provide some inputs for cause of this > and how can we debug what is causing. > > Below is op from catalina logs. > > > Apr 26, 2017 12:38:41 PM org.apache.coyote.AbstractProtocol pause > INFO: Pausing ProtocolHandler ["http-nio-61034"] > Apr 26, 2017 12:38:41 PM org.apache.catalina.core.StandardService > stopInternal > INFO: Stopping service Catalina > Apr 26, 2017 12:38:52 PM org.apache.catalina.loader.WebappClassLoader > clearReferencesJdbc > SEVERE: The web application [/MainframeJobRequest] registered the JDBC > driver [com.ibm.db2.jcc.DB2Driver] but failed to unregister it when the web > application was stopped. To prevent a memory leak > , the JDBC Driver has been forcibly unregistered. > Apr 26, 2017 12:38:52 PM org.apache.coyote.AbstractProtocol stop > INFO: Stopping ProtocolHandler ["http-nio-61034"] > Apr 26, 2017 12:38:52 PM org.apache.coyote.AbstractProtocol destroy > > > > Warm Regards, > Naveen Kumar Reddy N > > >
Tomcat Auto Shutdown issues
Hi Team, We are using Tomcat "7.0.61.0", and running on SUSE Linux Enterprise Server 11 (x86_64), Version 11, and PatchLevel 3. Our tomcat instance is going down due to below message, and its not a normal shutdown we are not sure why and who is causing to throw this messages and causing tomcat instance go down. Can anyone provide some inputs for cause of this and how can we debug what is causing. Below is op from catalina logs. Apr 26, 2017 12:38:41 PM org.apache.coyote.AbstractProtocol pause INFO: Pausing ProtocolHandler ["http-nio-61034"] Apr 26, 2017 12:38:41 PM org.apache.catalina.core.StandardService stopInternal INFO: Stopping service Catalina Apr 26, 2017 12:38:52 PM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc SEVERE: The web application [/MainframeJobRequest] registered the JDBC driver [com.ibm.db2.jcc.DB2Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak , the JDBC Driver has been forcibly unregistered. Apr 26, 2017 12:38:52 PM org.apache.coyote.AbstractProtocol stop INFO: Stopping ProtocolHandler ["http-nio-61034"] Apr 26, 2017 12:38:52 PM org.apache.coyote.AbstractProtocol destroy Warm Regards, Naveen Kumar Reddy N
warning in tomcat logs
TC 8.5.14 and noticed in the logs the following warning: "The truststoreProvider [AnyCert] does not support the certificateVerificationDepth configuration option" In our case, we're using Shib's AnyCert trust manager to accept any client cert on a particular connector as described here [1]. I noticed that now one can inject the trust manager directly via "trustManagerClassName" so I am planning to go that route to eliminate the warning from the logs. But I looked at JSSEUtils.java#getTrustManagers() and it looks like the warning is emitted for any algorithm other than "PKIX". My question is, what if an algorithm implementation doesn't care about "certificateVerificationDepth"? By setting different algorithm the user should realize that they are deviating from PKIX and therefore configuration parameters that apply to PKIX (such as "trustMaxCertLength" would not be passed down to the trust manager. Doesn't it make sense to be logged at INFO level? George [1] https://wiki.shibboleth.net/confluence/display/SHIB/TomcatClientCertAuthN
Re: Fwd: Identifying 64k size violation for __jspService methods loaded by Tomcat
Hello, I have retried using the following javac and jasper settings for my project (using ANT build) - and it still doesn't reveal those 64K errors even when the compilers are the same. I set my environment variables for catalina and java as part of my tomcat start script. And both ANT and Tomcat are using the same compiler as i understand from ant task documentation. Is there anything else I can do to reveal the 64k size errors on the method? KR, On 26 April 2017 at 11:24, Mark Thomas wrote: > On 26/04/17 10:33, Mohammed Manna wrote: > > Hello, > > > > Thanks for suggesting the solutions. This is closer to what I was > expecting > > in the original message which I sent in the past. Once again, I > apologise > > if I have made any Negative/Reactive comments about Apache no being > > supportive enough. I have been using various Apache libraries over the > past > > 7 years without any issues. But this particular Tomcat upgrade has caused > > me significant grief in managing large projects where 9/10 systems are > > legacy code base. I do agree that the JSPs need to be refactored to > remove > > any obsolescence. But until your response, I have only received responses > > where I was asked to upgrade to a different version, but I am more > curious > > to find out the root cause for this. > > > > Unfortunately, I have to leave with *enablePooling=TRUE, *since it might > > affect things. I will however try to reconfigure Jasper and use my native > > Java 1.8.121 to do all the compilation and see how things go. > > > > Unless I have misunderstood, Tomcat 8.0.43 will not stop this error but > > minimise the occurrences of it. Is this correct? > > Correct. The error handling code was refactored for 8.0.42 onwards to be > a little more efficient. It isn't much but if your code is on the border > line it might be enough to bring it back under the 64k. > > Mark > > > > > > > > Additionally, thanks to you for putting a lot more attention to it. > > > > KR, > > > > > > > > > > On 26 April 2017 at 09:58, Mark Thomas wrote: > > > >> On 26/04/17 09:06, Mohammed Manna wrote: > >>> Hello, > >>> > >>> I have emailed and posted a few questions over the web about this, but > >>> haven't received any helpful response. Since the upgrade to 8.0.39, my > >> web > >>> application is failing in various places since the Jasper compiler has > >> now > >>> got more debug information (and inturn __jspService method is now > bigger > >>> than 64k). > >> > >> First a correction. The changes were not made to introduce additional > >> debug information. The changes introduced additional - specification > >> required - error handling for tags. The changes were the result of > >> investigating a reported memory leak [1]. > >> > >>> I have done the following so far: > >>> > >>> 1) Kept mappedFile = TRUE > >>> 2) Kept suppressSMAP = FALSE > >>> > >>> This removes the failure, but now I have lost the JSP debugging > >> capability. > >>> Since Apache is not going to provide any support for this, could you > >> kindly > >>> assist me with the following: > >> > >> First you say Apache isn't going to provide you with any support > >> (despite this being your first post on this topic) then you ask this > >> Apache community for that same support. That isn't the best way to > >> motivate a group of volunteers to help you. > >> > >> The initial fix was in 8.0.37. > >> A regression was fixed in 8.0.40. > >> A more efficient solution was provided in 8.0.42. > >> An improved solution for simple tags was in 8.0.43 > >> > >> The first recommendation is to upgrade to 8.0.43. The more efficient > >> code introduced in 8.0.42 may help. > >> > >> Other configuration settings that can help reduce the size of your JSP > >> methods include: > >> > >> trimSpaces - true > >> enablePooling - false > >> > >> Note the disabling pooling may impact performance. It depends on lot on > >> the complexity of the tags. > >> > >>> 1) How can I identify my JSP pages which are going to have this issue? > >>> 2) I have tried using ANT build and compiled my JSPs. It simply passes > >> the > >>> build, but doesn't report any method size violation. Do you have any > >>> development mode support that can expose these affected methods. > >> > >> Do those pre-compiled JSPs then execute without error? > >> > >> Pre-compilation typically uses javac whereas on the fly compilation > >> typically uses JDT (the Eclipse Compiler). It is possible that > >> differences in the compilers means that a class compiles with one but > >
Re: Skip resource path in TLD scanner?
On 28/04/17 17:00, Matt Cosentino wrote: > Yes, it's other folders within WEB-INF. I turned on the TldScanner > logging and it is definitely what is causing the delay. My situation > probably isn't very typical. The delay varies in my various web > applications, the worst being about 20 seconds. It all adds up > though, and every second counts when our sites are down. There is a solution available but it is intended more for the embedded use case rather than a standard Tomcat install. Using it in a standard install would require (effectively) patching Tomcat. The general idea would be to use the TldPreScanned class. That does require all the TLDs to be listed in advance. On the plus side, no scanning delay. On the down side, adding TLDs requires code changes. Doing this with a standard Tomcat install requires changes to the JasperInitializer (hence the patch). I don't think there is a pure config way around that but I'll look into it. A better solution would probably be to make it easier to plugin in a custom TLDScanner - i.e. purely with config. If you'd like us to explore this option we should re-open 61052 and adjust accordingly. I don't think there is enough demand for filtering resource paths to make that worth implementing. One final thought. Are you running the web application from a WAR or an expanded directory? (The latter would be faster). Mark > > - Matt > > > -Original Message- From: Mark Thomas > [mailto:ma...@apache.org] Sent: Friday, April 28, 2017 7:28 AM To: > Tomcat Users List Subject: Re: Skip > resource path in TLD scanner? > > On 27/04/17 23:39, Matt Cosentino wrote: >> https://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html >> >> There is one for skipping jar files: >> >> tomcat.util.scan.StandardJarScanFilter.jarsToSkip > > > >> It skips /WEB-INF/classes/ and /WEB-INF/lib/, but it does not check >> any property to skip user defined paths. > > Is it other paths within WEB-INF you need to skip? > > When I read "skipping resource paths" I was thinking of skipping the > various places where Tomcat treat directories as JARs that then get > scanned for TLDs (which can be configured via the JarScanner). But it > sounds like skipping those won't help you. > > How sure are you that it is checking the directories below WEB-INF > that is the cause of the delay? That isn't a typical source of > start-up delay although it is certainly possible. > > Finally, what sort of delay are we talking out here? Seconds? > Minutes? > > Mark > > >> -Original Message- From: Mark Thomas >> [mailto:ma...@apache.org] Sent: Thursday, April 27, 2017 5:05 PM >> To: Tomcat Users List Subject: Re: Skip >> resource path in TLD scanner? >> >> On 27/04/17 21:17, Matt Cosentino wrote: >>> I need to skip some of the resource paths within WEB-INF. I know >>> there's a property for skipping jar files, but I couldn't find >>> one for resource paths. I reported this as a bug and was told >>> that the property exists. Where is it? >> >> Where have you looked? >> >> Mark > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Http2UpgradeHandler crash
On 28/04/17 21:17, Matt Cosentino wrote: > Tomcat crashed on us today, here is an excerpt from the crash log: The full log would be more helpful. > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > J 19003 org.apache.tomcat.jni.Socket.sendb(JLjava/nio/ByteBuffer;II)I (0 > bytes) @ 0x0599a2df [0x0599a280+0x5f] > J 42307 C2 org.apache.tomcat.util.net.SocketWrapperBase.flushBlocking()V (90 > bytes) @ 0x02663b84 [0x026632e0+0x8a4] > J 38363 C2 org.apache.tomcat.util.net.SocketWrapperBase.flush(Z)Z (20 bytes) > @ 0x046e5a18 [0x046e59e0+0x38] > j > org.apache.coyote.http2.Http2UpgradeHandler.sendStreamReset(Lorg/apache/coyote/http2/StreamException;)V+128 > j > org.apache.coyote.http2.Stream.close(Lorg/apache/coyote/http2/Http2Exception;)V+76 > J 43733 C2 org.apache.coyote.http2.StreamRunnable.run()V (12 bytes) @ > 0x0af4d104 [0x0af4c720+0x9e4] > J 36891 C1 > java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V > (225 bytes) @ 0x09a7797c [0x09a76940+0x103c] > J 41848 C1 java.util.concurrent.ThreadPoolExecutor$Worker.run()V (9 bytes) @ > 0x03ff180c [0x03ff1700+0x10c] > J 41853 C1 org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run()V > (25 bytes) @ 0x07e8194c [0x07e81840+0x10c] > J 30379 C1 java.lang.Thread.run()V (17 bytes) @ 0x0170dac4 > [0x0170d980+0x144] > v ~StubRoutines::call_stub > > In my web application log I found this at the same time: > > > org.apache.coyote.CloseNowException: Connection [389], Stream [67], This > stream is not writable > > at > org.apache.coyote.http2.Http2UpgradeHandler.reserveWindowSize(Http2UpgradeHandler.java:755) > > at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:721) > > at org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java:682) > > at org.apache.coyote.Response.doWrite(Response.java:522) > > at > org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:351) > > > There were more for additional streams at this same time. I've seen quite a > few of these CloseNowExceptions since upgrading to 8.5.14 from 8.5.11, but > this is the first time it has crashed Tomcat. What could be the cause? What > should I be looking for? Generally, the cause is a bug where the socket is closed multiple times. APR is particularly sensitive to that because of the native code. If you open a bug and attach the full crash log we can take a look. It rarely shows exactly where the problem is but we might get some pointers. We typically need to find the problems via code inspection. In terms of a way to avoid it, I'd suggest using the NIO connector with the OpenSSL TLS engine rather than APR. In most cases performance is comparable and because the native code is used for less of the I/O, the chances of crashes is reduced. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
