Re: Tomcat Auto Shutdown issues

2017-04-29 Thread Naga Ramesh
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

2017-04-29 Thread Naveen Nandyala - Vendor
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

2017-04-29 Thread George Stanchev
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

2017-04-29 Thread Mohammed Manna
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 

Re: Skip resource path in TLD scanner?

2017-04-29 Thread Mark Thomas
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

2017-04-29 Thread Mark Thomas
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