Tomcat 9.0.71 Anomalies
We experienced a very similar situation with Oracle connections not releasing. We did not hit an error state because our DBA team alerted us and we began to immediately fail-over to freshly restarted Tomcat instances. We recently upgraded Tomcat from v9.0.38 to v9.0.65. We also are using Spring in our application. When we saw this thread, for a rough test, we started up a new Tomcat v9.0.38 instance in the same production environment as the problematic v9.0.65 instances and started draining customers to the downgraded instance. The v9.0.38 instance is growing the number of connections within the bounds defined for our connection pool and is correctly releasing the connections when demand drops. We have since spun up several new v9.0.38 Tomcat instances and taken all of the 9.0.65 instances offline. Sorry, since our DBA team was pro-active enough to alert us before we started generating stack traces, I don't have any to share. Likewise we do not have GC or JVM dumps to share. We were in production break/fix mode and in a rush to keep our production environment responsive to our customers. R. Mark Harris Information Technology Systems Oregon Department of Corrections -Original Message- From: Mark Thomas Sent: Saturday, March 4, 2023 12:45 AM To: users@tomcat.apache.org Subject: Re: Tomcat 9.0.71 Anomalies On 03/03/2023 20:19, jonmcalexan...@wellsfargo.com.INVALID wrote: > Hi Mark, > > On the slowness, this is when they are retrieving random .js files from the > exploded war file after deployment. To clarify, these are .js files loaded directly from the file system? They are not packaged in a JAR file? > It's taking an a long > amount of time. Some of these are quite large, like 2MB or more. When the > issue shows, doing a curl we get to here and then it pauses for some time > before it feeds back the data. > > * Trying **.**.**.**:8443... > * TCP_NODELAY set > * Connected to server port 8443 (#0) > * ALPN, offering h2 > * ALPN, offering http/1.1 > * TLSv1.3 (OUT), TLS handshake, Client hello (1): > * TLSv1.3 (IN), TLS handshake, Server hello (2): > * TLSv1.2 (IN), TLS handshake, Certificate (11): > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): > * TLSv1.2 (IN), TLS handshake, Server finished (14): > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): > * TLSv1.2 (OUT), TLS handshake, Finished (20): > * TLSv1.2 (IN), TLS handshake, Finished (20): > * SSL connection using TLSv1.2 / > * ALPN, server accepted to use http/1.1 > * Server certificate: > * subject: > * start date: > * expire date: > * issuer: > * SSL certificate verify result: unable to get local issuer certificate > (20), continuing anyway. >> GET HTTP/1.1 >> Host: >> User-Agent: curl/7.65.3 >> Accept: */* >> > > And it just hangs out here before finally getting the requested file. How repeatable is this? How long does it hang before delivering content? Is it always the same or does it vary. Which connector are you using? What Tomcat version did you upgrade from? How does the problem before the upgrade compare to the problem after the upgrade? What component is serving the content? Is it Tomcat's default servlet or is it something else? When it happens, take 3 thread dumps a few seconds apart. The aim is to figure out why it is hanging. > In looking at the catalina.out log file, I am not seeing any > errors/stack-traces. > > Any ideas as to what may be causing this? Not at the moment. The information requested above should at least narrow down which parts we need to think about. Mark > > Thank you, > > Dream * Excel * Explore * Inspire > Jon McAlexander > Senior Infrastructure Engineer > Asst. Vice President > He/His > > Middleware Product Engineering > Enterprise CIO | EAS | Middleware | Infrastructure Solutions > > 8080 Cobblestone Rd | Urbandale, IA 50322 > MAC: F4469-010 > Tel 515-988-2508 | Cell 515-988-2508 > > jonmcalexan...@wellsfargo.com > This message may contain confidential and/or privileged information. If you > are not the addressee or authorized to receive this for the addressee, you > must not use, copy, disclose, or take any action based on this message or any > information herein. If you have received this message in error, please advise > the sender immediately by reply e-mail and delete this message. Thank you for > your cooperation. > >> -Original Message- >> From: Mark Thomas >> Sent: Friday, March 3, 2023 1:32 AM >> To: users@tomcat.apache.org >> Subject: Re: Tomcat 9.0.71 Anomalies >> >> On 02/03/2023 21:54, jonmcalexan...@wellsfargo.com.INVALID wrote: >>> Hello gentle beings, >>> >>> I have a couple of application teams having issues since getting >>> upgraded to >> Tomcat 9.0.71. >> >> Upgrading from which Tomcat version? >> >>> The main one has to do with an application that has run fine in the >>> past is >> now exceeding max cursors with their
Manager App not working with Windows authentication enabled
Environment: IIS 7.5 Tomcat 7.037 AJP/1.3 connector (redirector.dll) v 1.2 Java 7 We have a requirement for a new intranet application that it use Windows authentication. We have this working in our new application. We do have IIS, the connector and Tomcat serving up the application with no problems. What did happen is that we discovered that the manager application that comes with Tomcat no longer is accessible. We have some staff that use the manager app routinely. We did try to set up two AJP connectors, one defined in the server.xml with tomcatAuthentication=true and another set to false. In the AJP property files we set the second one to only be mapped to the manager URL. This did not work as we expected. Anyone have any ideas on how to get the manager application working? Excerpt from server.xml: ___ GlobalNamingResources Resource auth=Container description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory name=UserDatabase pathname=E:\Tomcat\32Bit\7.0.37\conf\tomcat-users.xml type=org.apache.catalina.UserDatabase/ /GlobalNamingResources Service name=Catalina Connector connectionTimeout=12000 maxThreads=300 port=1 protocol=AJP/1.3 tomcatAuthentication=false/ Connector connectionTimeout=12000 maxThreads=300 port=10005 protocol=AJP/1.3 tomcatAuthentication=true/ Connector connectionTimeout=2 port=9080 protocol=HTTP/1.1 redirectPort=8443/ Engine defaultHost=localhost jvmRoute=WA1 name=Catalina Realm className=org.apache.catalina.realm.LockOutRealm Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ /Realm Host appBase=webapps autoDeploy=true name=localhost unpackWARs=true Valve className=org.apache.catalina.valves.AccessLogValve directory=logs pattern=%h %l %u %t quot;%rquot; %s %b prefix=localhost_access_log. suffix=.txt/ /Host /Engine /Service Excerpt from worker.properties file __ worker.list=WA1,MGR worker.WA1.type=ajp13 worker.WA1.host=localhost worker.WA1.port=1 worker.WA1.connection_pool_size=300 worker.WA1.connection_pool_timeout=12 worker.MGR.type=ajp13 worker.MGR.host=localhost worker.MGR.port=10005 worker.MGR.connection_pool_size=300 worker.MGR.connection_pool_timeout=12 Excerpt from uriworkermap.properties: ___ /manager|/*=MGR R. Mark Harris
RE: Manager App not working with Windows authentication enabled
Sorry, guess I was not clear enough. We are using Microsoft's IIS to front-end Tomcat, not the Apache HTTP server. Apache HTTP server is not an option for our environment. We would prefer to use the Windows authenticated user passed to Tomcat by IIS, but are open to anything that works reliably. As I said, our custom application is working great in this environment, but the manager app is not. We are having trouble associating the roles that the manager app is expecting with the authenticated user. We have tried altering the tomcat-users file just about every which way we could think of. Essentially we need any way to associate the authenticated user with the manager-gui that the manager app is expecting. Would we need to implement a custom realm to make this work? - Mark Harris - -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Tuesday, March 19, 2013 3:28 PM To: Tomcat Users List Subject: Re: Manager App not working with Windows authentication enabled Harris Mark R wrote: Environment: IIS 7.5 Tomcat 7.037 AJP/1.3 connector (redirector.dll) v 1.2 Java 7 We have a requirement for a new intranet application that it use Windows authentication. We have this working in our new application. We do have IIS, the connector and Tomcat serving up the application with no problems. What did happen is that we discovered that the manager application that comes with Tomcat no longer is accessible. We have some staff that use the manager app routinely. We did try to set up two AJP connectors, one defined in the server.xml with tomcatAuthentication=true and another set to false. In the AJP property files we set the second one to only be mapped to the manager URL. This did not work as we expected. Setting tomcatAuthentication=false in this case means that Tomcat is going to rely on the authenticated user-id sent to it by the front-end, through AJP. So you should authenticate the user at the Apache httpd front-end level. Anyone have any ideas on how to get the manager application working? How would you like the users of the manager application to be authenticated ? also via Windows Integrated Authentication, or at the Apache httpd level, via some other mechanism ? For a simple case, you could for example do this at the Apache httpd level : Location /manager setHandler jakarta-servlet AuthType Basic AuthName tomcat-manager require user x y z ... ... /Location (and set tomcatAuthentication=false) (setHandler jakarta-servlet in that Location section is roughly equivalent to JkMount /manager worker1) This syntax is explained in one of the on-line AJP connector's info pages on the tomcat website, at the very end of the page. - 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
