remote jmx monitoring through ssh tunnel
Server : Debian 8, Tomcat 9.0.29, OpenJDK 1.8 Client : MacOS Mojave After reading a recent thread here on monitoring database connections via JMX I am trying to set it up on a sandbox. I would prefer to use an SSH tunnel to connect than open up ports on the firewall if possible. In CATALINA_BASE/bin/setenv.sh I have the following : CATALINA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false" In CATALINA_BASE/conf/server.xml I have a listener configured : Upon startup I see in logs : INFO [main] org.apache.catalina.mbeans.JmxRemoteLifecycleListener.createServer The JMX Remote Listener has configured the registry on port [10001] and the server on port [10002] for the [Platform] server $ netstat -an | grep 10001 tcp4 0 0 127.0.0.1.10001*.*LISTEN tcp6 0 0 ::1.10001 *.*LISTEN On my local machine I have a tunnel set up as follows : ssh -N -L10001:localhost:10001 -L10002:localhost:10002 user@remotehost (where user is the user tomcat is running under) When I try to add a remote JMX connection in VisualVM on my client machine to localhost:10001 I get an error dialog after a brief delay with the message "Cannot connect to localhost:10001 using service:jmx:rmi:///jndi/rmi://localhost:10001/jmxrmi". If I change it to port 10002 I get the same error. On the server at this time : $ netstat -an | grep 10001 tcp4 0 0 127.0.0.1.10001*.*LISTEN tcp6 0 0 ::1.10001 *.*LISTEN tcp4 0 0 127.0.0.1.62637127.0.0.1.10001TIME_WAIT If I try to use jconsole connecting to port 10001 I get the error "Connection failed: non-JRMP server at remote endpoint". Connecting to port 10002 I get the error "Connection failed: no such object in table" I've been through the tomcat configuration documentation a couple times but I can't see what else I need to configure. Any suggestions? Thanks Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ServletRequest Obj Randomly not Processing x-www-form-urlencoded parms
On 12/9/2019 5:39 AM, Konstantin Kolinko wrote: вс, 8 дек. 2019 г. в 08:09, Jerry Malcolm : I have ajax code that sends requests to TC in a REST-style process. I send the parms url-encoded in the body. This has worked untouched literally for years. I have some new data objects in my db that "should be" sending the same type of requests through the same javascript routines. But for some inexplicable reason, the HttpServletRequest object is randomly deciding to not process the parms. When I try to enumerate the parms, I get none. Any parm I request comes back not found. I added some code to read the body myself (request.getReader(), etc). When the parms are available as it normally works, the reader is empty, which is what I would expect since it's been read by the request obj. But when the request object tells me I have no parms, I can read the entire url-encoded parm string from the reader, which if I understand things, means the request object never tried to read the stream, unless it somehow restores the stream after a read (??). But the important point I determined is that the parms are indeed present in the body... just not processed. [...] Thanks to all of the responders on this problem. From the beginning of this problem, I was convinced that I was doing something bad wrong to cause this. I think now I have finally identified the 'bad thing'. Periodically the model code that runs in the request determines that I need to spin off another thread to do some background work. That thread needs a few parameters from the request object. So I pass the request object into the thread object. I realize now that doing that is a horrible thing to do. I was not aware until yesterday that request objects are pooled and recycled. So I figured holding onto the request object a little longer before it is discarded for that thread to use was not going to be a problem. Obviously, that was incorrect. From what I can deduce, the main request thread finishes and returns. The request object recycle code runs and the object is returned to the pool. However, then the async thread later gets a parm and must apparently still be able to use the request object even though it's back in the pool. The 'parametersProcessed' gets set to true. Then the next request comes in, and that request object is assigned with parametersProcessed=true. I'm assuming the fix is to get everything I need out of the request object and pass those parm values to the thread before returning instead of passing the request object itself to the thread. Does all of this sound plausible as the source for this. The good news is that I'm still teachable... :-) Jerry - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Design Patterns in Tomcat
Chris, On Mon, 9 Dec 2019 at 17:10, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > M, > > On 12/8/19 17:10, M. Manna wrote: > > Hi All, > > > > A numpty question as its best, but I was trying to summarise the > > design patterns used for tomcat. So far I could see the following, > > but shouldn't be limited to: > > > > 1) Mediator 2) Observer 3) Factory 4) Builder 4) Adapter > > > > Perhaps I missed any confluence link or something that confirms > > it? > > Don't forget iterator, interceptor, etc. > > We don't bother to track which design patterns are in use in Tomcat. > Some of them are obvious due to their class names or behavior, but > there is no documentation about what is being used where. > > There is also the problem of having a very large number of named > design patterns, many of which are variations on a theme. You may see > code that looks like publish/subscribe and others may call that > observer/observable, etc. Some patterns are so obvious as to not > require naming at all (e.g. "State"). > > If you'd like to hunt through the code and find examples of carious > patterns and document them -- e.g. in the Wiki -- that would be fine, > but I don't think any committer is currently interested in such a task. i guess it’s more or less what I was sexpecting. Let me work on the page and perhaps I wi also provide 1/2 examples to support it. As long as folks keep it correct, it should be a good source. Thanks, > > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3uf/oACgkQHPApP6U8 > pFgieQ/+LSNxlzLoM8XBtE/sNQlM+HXokdAAenakQb7jGHzKYGo7ElBL3+o0FORg > /4HRQYO7sO9PkWDmBY8oAlxlXPdCwx6KSkK2ZFMi8kW4cOabqLXl0l7KpOI2TGNK > u7aq7jJxN8k/OmcBdlIutYpKScB//kp9wDei6G2lEGdoQh2qMMgsWN7q9J9IGAO2 > CTB3JMVTy2LQGbXSPBGhNgRhpL4DykoHqpLCflsA9rhPGFVnN+cnCsFmiI3XREHD > N/ap5ffXA2yOeOIuR5vhBolQJ2/3bGOQdIUrliGXMEv2hefslP+fQYudOAYzapju > MO5VBVwOhtL0cZlVdOAgMJRL4V/Y91rSIXIS1gw/RKGV5cdEl+6VoyQhEVmRQa6u > gHQ2HWrT+MyAV72YBulalPJy3c1vlr3Lna5kJFsxWB9rwdGZLv2xWIrWmINecdI1 > GAadRCzI0QOPA1leoq0ZdjtLvuk3W0m9+98V/uy9nrz6eyZ2hm2dFoTRvM2bbLda > +aSwQssfaiq3QyoOxOmpeb3tWzQMXHeeoq6u5tnCwktNXUV78ZE4q6IiU9wcW8/L > Z1/0VwhEWTF/cP8MSnqhMquEYoFVnFv2HBRE8eYIshKw2KrnlIzjYwGHCYqjRTNK > DNSYvvuzf7s5pdzG7EtrrvOVNW7mH5Qtvs2hx1C55BijJRf3Rx0= > =aczA > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Design Patterns in Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 M, On 12/8/19 17:10, M. Manna wrote: > Hi All, > > A numpty question as its best, but I was trying to summarise the > design patterns used for tomcat. So far I could see the following, > but shouldn't be limited to: > > 1) Mediator 2) Observer 3) Factory 4) Builder 4) Adapter > > Perhaps I missed any confluence link or something that confirms > it? Don't forget iterator, interceptor, etc. We don't bother to track which design patterns are in use in Tomcat. Some of them are obvious due to their class names or behavior, but there is no documentation about what is being used where. There is also the problem of having a very large number of named design patterns, many of which are variations on a theme. You may see code that looks like publish/subscribe and others may call that observer/observable, etc. Some patterns are so obvious as to not require naming at all (e.g. "State"). If you'd like to hunt through the code and find examples of carious patterns and document them -- e.g. in the Wiki -- that would be fine, but I don't think any committer is currently interested in such a task. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3uf/oACgkQHPApP6U8 pFgieQ/+LSNxlzLoM8XBtE/sNQlM+HXokdAAenakQb7jGHzKYGo7ElBL3+o0FORg /4HRQYO7sO9PkWDmBY8oAlxlXPdCwx6KSkK2ZFMi8kW4cOabqLXl0l7KpOI2TGNK u7aq7jJxN8k/OmcBdlIutYpKScB//kp9wDei6G2lEGdoQh2qMMgsWN7q9J9IGAO2 CTB3JMVTy2LQGbXSPBGhNgRhpL4DykoHqpLCflsA9rhPGFVnN+cnCsFmiI3XREHD N/ap5ffXA2yOeOIuR5vhBolQJ2/3bGOQdIUrliGXMEv2hefslP+fQYudOAYzapju MO5VBVwOhtL0cZlVdOAgMJRL4V/Y91rSIXIS1gw/RKGV5cdEl+6VoyQhEVmRQa6u gHQ2HWrT+MyAV72YBulalPJy3c1vlr3Lna5kJFsxWB9rwdGZLv2xWIrWmINecdI1 GAadRCzI0QOPA1leoq0ZdjtLvuk3W0m9+98V/uy9nrz6eyZ2hm2dFoTRvM2bbLda +aSwQssfaiq3QyoOxOmpeb3tWzQMXHeeoq6u5tnCwktNXUV78ZE4q6IiU9wcW8/L Z1/0VwhEWTF/cP8MSnqhMquEYoFVnFv2HBRE8eYIshKw2KrnlIzjYwGHCYqjRTNK DNSYvvuzf7s5pdzG7EtrrvOVNW7mH5Qtvs2hx1C55BijJRf3Rx0= =aczA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat is throwing an error Invalid byte tag in constant pool:19
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Steven, On 12/9/19 06:45, Nelligan, Steven M wrote: > > Thank you for your response... > > We run multiple servers for our application. > > We have a configuration as follows: 1. Portal ... running tomcat > 7.0_45 and java 7... this is the outward facing running jetspeed. > This is the server throwing the errors 2. Tomcat ... running tomcat > 7.0_45 and java 7... this is our back-end business logic server 3. > Mule .. enterprise service bus broker ... no tomcat running java 7 > 4. AiM .. our ERP software from a third party ... runing tomcat_9 > and java 11 > > We cannot upgrade Java at this point, because of an old third party > application running on the portal. It requires Java 7. We are > currently exploring new packages to replace it, but this will take > some time to finalize. > > I've attached the catalina log showing the error. The error > appears on startup of Tomcat. > > I tried to replace the annotation_api.jar with a newer version, > somewhere on the web, it was posted that replacing this jar file > with a new version solved his problem; which was simular to mine. All you have to do is upgrade to Tomcat 7.0.latest and you should not see this problem. Now, since the vendor of your "Portal" application has moved to Java 11, it looks like they have also compiled the application with Java 11 as well, and the class files will likely not be compatible with Java 7. So you will find that once Tomcat gets past this problem, you may have a host of other problems caused by this version mismatch. Thanks, - -chris > -Original Message- From: Mark Thomas > Sent: Monday, December 9, 2019 5:17 AM To: users@tomcat.apache.org > Subject: Re: Tomcat is throwing an error Invalid byte tag in > constant pool:19 > > On 09/12/2019 00:57, Nelligan, Steven M wrote: >> >> I am trying to rebuild my applications and all of a sudden, I am >> getting the following error: >> >> Our backend application (from third party has been updated) It is >> using Java 11. > > You'll need at least 7.0.88 for Java 11 support. > >> When I first tried this a couple of weeks ago... I needed up >> trying to upgrade Tomcat to the latest release of 7.0_94 > > That is what I would recommend (or latest 8.5.x / 9.0.x but that is > probably changing too much in one go). > >> Everything started to fall apart, the javax modules were failing, >> etc. I finally realized I was chasing my tail. Every time I got >> one thing working, two more broke. >> >> Restored everything back and went through the rebuild. > > You are going to have to try this again. Can I suggest you post the > first error you see here and we can try and talk you through fixing > it. > >> I tried to copy the annotation_api.jar file from Tomcat 7.0_94 >> into tomcat 7.0_45 but nothing would deploy... > > Why do that? > > 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 > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3ufdcACgkQHPApP6U8 pFhKiA/7BBK+AOtdAtTgJRoFQXUyUQoEACpD5YonFcUcYIsfl14lwMIhPUamjm+d OmGMIZg+HKiZXaOCNp2mdWLrPbh/1fHWWxDSXL8E7R535CppJ9p8PUf2Jj5mD4Ex 6Vb34RQ3KGjNThepHG3jeSbE5OFt+E3hHqHLmHJ0pNaxJffI+uVtaI0zL+KLtb+8 Vv9VRZKGp49GjyLwzF/0AGRK6XsJaVLgzUSRALUdLlY+o6k1WdfF4rn/BhL3usiu tun7vgHHJW36C5EAm/O19p+RJH0KjS4fmycCj3P8X6k3lDrYBnmnXCaJBLVI6Idw xVDawgPccKKKrV/ZPsyjI0/IJLOpua7f1rRFxGSS1KOIzZo4b9YqDidmY/3YmX/r hwOiIfVp0+Gng9TXjdyTua5aN0MBDiZH/bltkGb/F7dAMbVKz2mKWtt/TdcZDDGH N/CBbLHcF+5A8Mvqy3nroFn4ji1kD2hgNhoQ5vDO90uDLBLcPa8/Ux8dfCdAJ82j aLwZk0IfWmxhqQs1mTDsAQpGRVL3/r5M6I9iL5sHKN3Vmi8t8dSK8GB84rzt9eV1 MzoUVk2JGktOS6mnTNN3PkIjtJFc+G34vWgm9a4fTa1ttJ9ETtgufuo/Rouaa4vs E5H3oczbcd8780y9YimA8WTjyvX71/xxKOPUK43WOnF1BIvjBSw= =yYAV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Double Slash Support in Tomcat 9.0.27
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 12/9/19 04:50, André Warnier (tomcat/perl) wrote: > Hi Christopher. > > I believe that yours is a really good explanation of why Tomcat > collapses consecutive slashes in URLs. It's certainly worth a FAQ > article, in case the question ever pops up again. > > It maybe even be worth a note somewhere in the main documentation, > such as where it explains how Tomcat actually maps URLs to webapps. > Except that I can't locate the documentation which specifically > explains this.. Maybe this is because Tomcat normally refers to the > Servlet Spec for this ? > > The closest I find is here : > http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Naming > Maybe inserting a note to the effect of 'Note: before any of the > mapping below takes place, Tomcat collapses any consecutive "/" > characters in the path portion of the URL to a single "/". The > complete explanation is here : --> FAQ article" ' Sure. Feel free to go ahead and add that. There may be a place in the security documentation that might be appropriate to add a reference, too. Like under "security considerations" or something. - -chris > On 05.12.2019 17:13, Christopher Schultz wrote: André, > > On 12/5/19 04:55, André Warnier (tomcat/perl) wrote: Christopher, I believe that the problem of the OP is that either this filter or the application, *relies* on the fact that Tomcat would NOT collapse multiple consecutive slashes in the URL, to a single slash. That (the non-collapsing) seems to have been the case in some previous versions of Tomcat, and has apparently been changed in more recent versions of Tomcat (and probably rightly so, to adhere more strictly to the specs). > > Actually, it's somewhat in *violation* of the specs. But it's a > generally-accepted violation because it allows security rules to > actually remain sane. > > If you want to protect "/foo/bar.html" which maps to a file on the > disk, you'll find that the filesystem collapses slashes and will > load that same file regardless of how many extra slashes you put in > there. "/foobar.html" is going to give you the same result. > > The same is true for multiple levels like "/foo/bar/bar.html". If > you want to protect all files in "/foo/bar" it's not practical to > add protections for "/foo/bar/" and "/foo//bar/" and "/foo///bar/" > and ... you see where I'm going with this. > > So the server decides that slash-collapsing will allow security > constraints to be more practically applied. > > What if we get super-spec-compliant and allow those extra slashes? > Well, you'd have to get really (and, IMHO, /overly/) strict about > how those slashes are treated. In Java, you'd have to do something > like this : > > String path = ... // file-path from request String docRoot = ... // > docroot base, absolute File file = new File(docRoot, path); > if(!file.exists()) // return 404 > if(!path.equals(file.getAbsolutePath().substring(docRoot.length())) > > // return 404 > > That last check will check to make sure that the path requested by > the client *exactly equals* that of the path on the disk. That > means that multiple-slashes are essentially forbidden when > requesting disk-files. > > (It gets more fun when you are requesting a directory which has an > "index file" like index.html and you have to decide whether or not > it's okay to load that file automatically, even though the client > didn't specifically request it.) > > So now we are spec-compliant. Yay! Except that all those sloppy > webmasters links no longer work because they do all kinds of weird > URL manipulations that don't always result in a perfectly-clean > URL. So we've achieved spec-compliance and inconvenienced users. > Did we really achieve anything? Those multi-slash URLs were never > going to work. It is really a big deal to just ... let them work? > So we collapse slashes and everything is fine. Nobody is really > going to complain if /foo//bar.html and /foo/bar.html both work > instead of one of them returning 404. > > What about resource that are *not* on a disk? Like servlets and > stuff like that? Well, the servlet spec allows us to map to URL > patterns of various types. Some are exact, others prefixes, etc. We > can also define security constraints with the same kind of > url-pattern basis. Generally, those things should agree. What > happens when you introduce multiple-slashes in there? > > Well, nobody is ever going to map a bunch of additional slashes to > make their servlets work properly. So we are back to the same > problem as the on-disk-file: the multiple-slashes are essentially > forbidden if we want to be super-spec-compliant. So we relax a > little and take the practical approach: collapse slashes and move > on with our lives. This has the added benefit of making security > constraints more consistent, and fewer mistakes. And encouraging > fewer security
RE: Tomcat is throwing an error Invalid byte tag in constant pool:19
Thank you for your response... We run multiple servers for our application. We have a configuration as follows: 1. Portal ... running tomcat 7.0_45 and java 7... this is the outward facing running jetspeed. This is the server throwing the errors 2. Tomcat ... running tomcat 7.0_45 and java 7... this is our back-end business logic server 3. Mule .. enterprise service bus broker ... no tomcat running java 7 4. AiM .. our ERP software from a third party ... runing tomcat_9 and java 11 We cannot upgrade Java at this point, because of an old third party application running on the portal. It requires Java 7. We are currently exploring new packages to replace it, but this will take some time to finalize. I've attached the catalina log showing the error. The error appears on startup of Tomcat. I tried to replace the annotation_api.jar with a newer version, somewhere on the web, it was posted that replacing this jar file with a new version solved his problem; which was simular to mine. Steve -Original Message- From: Mark Thomas Sent: Monday, December 9, 2019 5:17 AM To: users@tomcat.apache.org Subject: Re: Tomcat is throwing an error Invalid byte tag in constant pool:19 On 09/12/2019 00:57, Nelligan, Steven M wrote: > > I am trying to rebuild my applications and all of a sudden, I am getting the > following error: > > Our backend application (from third party has been updated) It is using Java > 11. You'll need at least 7.0.88 for Java 11 support. > When I first tried this a couple of weeks ago... I needed up trying to > upgrade Tomcat to the latest release of 7.0_94 That is what I would recommend (or latest 8.5.x / 9.0.x but that is probably changing too much in one go). > Everything started to fall apart, the javax modules were failing, etc. I > finally realized I was chasing my tail. > Every time I got one thing working, two more broke. > > Restored everything back and went through the rebuild. You are going to have to try this again. Can I suggest you post the first error you see here and we can try and talk you through fixing it. > I tried to copy the annotation_api.jar file from Tomcat 7.0_94 into tomcat > 7.0_45 but nothing would deploy... Why do that? 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
Re: ServletRequest Obj Randomly not Processing x-www-form-urlencoded parms
вс, 8 дек. 2019 г. в 08:09, Jerry Malcolm :
>
> I have ajax code that sends requests to TC in a REST-style process. I
> send the parms url-encoded in the body. This has worked untouched
> literally for years. I have some new data objects in my db that "should
> be" sending the same type of requests through the same javascript
> routines. But for some inexplicable reason, the HttpServletRequest
> object is randomly deciding to not process the parms. When I try to
> enumerate the parms, I get none. Any parm I request comes back not
> found. I added some code to read the body myself (request.getReader(),
> etc). When the parms are available as it normally works, the reader is
> empty, which is what I would expect since it's been read by the request
> obj. But when the request object tells me I have no parms, I can read
> the entire url-encoded parm string from the reader, which if I
> understand things, means the request object never tried to read the
> stream, unless it somehow restores the stream after a read (??). But
> the important point I determined is that the parms are indeed present in
> the body... just not processed.
>
> [...]
I usually have the following in the pattern of AccessLogValve in my
configurations:
[%{org.apache.catalina.parameter_parse_failed}r
%{org.apache.catalina.parameter_parse_failed_reason}r]
Those request attributes are set in Tomcat whenever a problem is
encountered by parameter parsing, e.g. an IOException if a client
aborts the request. (The methods to process parameters in Servlet API
do not have a way to report any errors). Those attributes can be used
by org.apache.catalina.filters.FailedRequestFilter
http://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#Failed_Request_Filter
You may look where those attributes are set in the source code.
Mark wrote:
> Issues like this can be caused if a reference to a request or response
> is retained longer than it should be. You can try setting:
> -Dorg.apache.catalina.connector.RECYCLE_FACADES=true
+1.
https://cwiki.apache.org/confluence/x/yColBg
https://cwiki.apache.org/confluence/display/TOMCAT/Troubleshooting+and+Diagnostics#TroubleshootingandDiagnostics-CommonTroubleshootingScenario
> I fired up my Windows laptop TC 9.x and got the exact same symptoms.
You may also try with Tomcat 9.0.30 - release candidate is available
and is currently being voted - see dev@ mailing list.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat is throwing an error Invalid byte tag in constant pool:19
пн, 9 дек. 2019 г. в 03:58, Nelligan, Steven M : > > > I am trying to rebuild my applications and all of a sudden, I am getting the > following error: > > Our backend application (from third party has been updated) It is using Java > 11. > > My tomcat servers are running version 7.34 of tomcat and version 1.7.0_45. 1.7.0_45 is the version of Java? But you say that those web applications need at least Java 11? > I have rebuilt and deploy a large number of our Apps; but there are about 4 > with the following error: > SEVERE: Unable to process Jar entry [module-info.class] from Jar > [jar:file:/G:/Tomcat7/temp/44-bannertools/WEB-INF/lib/jaxb-api-2.3.0.jar!/] > for SEVERE: Unable to process Jar entry [module-info.class] from Jar > [jar:file:/G:/Tomcat7/temp/44-bannertools/WEB-INF/lib/jaxb-api-2.3.0.jar!/] > for annotations > org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag > in constant pool: 19 > at > org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:133) Sounds a lot like this issue that I answered a year ago: https://stackoverflow.com/questions/52867430/invalid-byte-tag-in-constant-pool-19-error-message > > When I first tried this a couple of weeks ago... I needed up trying to > upgrade Tomcat to the latest release of 7.0_94 The latest release of Tomcat 7 is 7.0.96, released in July. > Everything started to fall apart, the javax modules were failing, etc. I > finally realized I was chasing my tail. > Every time I got one thing working, two more broke. > > Restored everything back and went through the rebuild. > > I tried to copy the annotation_api.jar file from Tomcat 7.0_94 into tomcat > 7.0_45 but nothing would deploy... > > I'm at a loss on what could be happening > > Any help would be appreciate any guidance. > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Crashed when the concurrent Users reached 150
On 09/12/2019 06:41, Jayaram Ponnusamy wrote: > Thanks for your Valuable Comments: > We are using Apache Tomcat/8.0.50 and Mod_JK mod_jk/1.2.28 > > The Above configuration made by some consultant. We are in the situation to > correct all the things to make it for high availability. > Also we are in the process of upgrading the apache to 2.4.25 with mod_jk/ > 1.2.42. And Event MPM instead of Prefork. > > Please let us know do we need to use worker MPM also or EVENT MPM is fine? > If Event MPM with below Configuration then how many concurrent users can > access the site and what are the relevant changes needs to be done on > Tomcat Side? > On Tomcat Servers We have 16GB RAM with 8CPU [Two Nodes] > > # event MPM > > StartServers 1 > ServerLimit 7 > MinSpareThreads 250 > MaxSpareThreads 2500 > ThreadsPerChild 500 > ThreadLimit 500 > MaxRequestWorkers 3500 > MaxConnectionsPerChild 0 > > > > # Tomcat Configuration > URIEncoding="UTF-8" emptySessionPath="true" maxThreads="600" > minSpareThreads="10" connectionTimeout="-1" /> > URIEncoding="UTF-8" maxThreads="600" minSpareThreads="100" > connectionTimeout="2" acceptCount="2000" /> > > > # Tomcat Configuration > -Xms2048M -Xmx6144M -XX:PermSize=1024m -XX:MaxPermSize=2048m > > > > > On Thu, Dec 5, 2019 at 7:27 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Jayaram, > > On 12/5/19 03:19, Jayaram Ponnusamy wrote: We are using apache 2.2.21 on RHEL6.9 and in Backend we are using Tomcat AppServer with JavaBased CMS. Our Server Architecture is *(F5 [For Load Balance] -> Apache WebServer [For Redirection & URL Mapping] -> Tomcat AppServer [Running a Java Based CMS]).* > > That version of Apache httpd is pretty old and unsupported. RHEL 6.9 > is also out of support (if I'm reading their Wikipedia page > correctly). You may want to upgrade everything while you are looking > at all this. > We are using Apache to connect Tomcat by MOD_JK and mapping the URL (Attached VirtualHost.conf), and No applications/code are running on WebServers. 1. Two TomcatServers (8 CPU & 16GB RAM on Each Servers) 2. Two WebServers (4 CPU & 8GB RAM on Each Servers) *PROBLEM:* When the Child Process count is reached / crossed 200 like below then site is not accessible > > Do you mean that new connections from httpd -> Tomcat cannot be made? > when the child processes reached 300 or More than site crashed > > Please define "crashed". Got an exception? JVM crash (with hs_pid* > file)? Kernel panic? > and then we bring the site back by restarting Tomcat & Apache HTTP. > > Do you need to restart httpd? Or only Tomcat? Or will restarting httpd > work? > Kindly please check my configuration and help to allow at-least 500 concurrent users. *CONFIGURATION:* * httpd.conf* StartServers 80 ServerLimit 3500 MaxClients 3500 MaxRequestsPerChild 0 StartServers 6 MaxClients 230 MinSpareThreads 75 MaxSpareThreads 150 ThreadsPerChild 25 MaxRequestsPerChild 0 > > Which MPM are you actually using? You have listed both prefork and > worker. AFAICT you have to pick one at runtime. > > For prefork, the maximum number of connections you should expect to be > made to each Tomcat backend is 3500 (the value of MaxClients). > > For worker, the maximum number of connections you should expect to be > made to each Tomcat backend is 230. > *Tomcat:* >>> redirectPort="8443" URIEncoding="UTF-8" emptySessionPath="true" maxThreads="600" minSpareThreads="10" connectionTimeout="-1" /> >>> URIEncoding="UTF-8" maxThreads="600" minSpareThreads="100" connectionTimeout="2" acceptCount="2000" /> > > Note that AJP connections are expected to be persistent; they don't > close when the request has completed. They don't even really do "keep > alive" in the same sense as HTTP keepalive. It's more like "always > keepalive". Once an httpd process opens a connection to a Tomcat > instance, that connection will remain open for quite a while as long > as requests continue to be made. > > If you are using prefork MPM, the the version of Tomcat you are using > is critical to understanding what is happening, here. If you are using > a BIO-based connector, then you will need to increase the number of > threads on each Tomcat server from 600 to 3500. > > If you are using the worker MPM, then your Tomcat should be able to > handle the 230 maximum connections configured there. TL;DR - Try switching to the NIO AJP connector on Tomcat. Take a look at this session I uploaded from TomcatCon London. You probably want to start around 35:00 and the topic of thread exhaustion. https://youtu.be/2QYWp1k5QQM Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat is throwing an error Invalid byte tag in constant pool:19
On 09/12/2019 00:57, Nelligan, Steven M wrote: > > I am trying to rebuild my applications and all of a sudden, I am getting the > following error: > > Our backend application (from third party has been updated) It is using Java > 11. You'll need at least 7.0.88 for Java 11 support. > When I first tried this a couple of weeks ago... I needed up trying to > upgrade Tomcat to the latest release of 7.0_94 That is what I would recommend (or latest 8.5.x / 9.0.x but that is probably changing too much in one go). > Everything started to fall apart, the javax modules were failing, etc. I > finally realized I was chasing my tail. > Every time I got one thing working, two more broke. > > Restored everything back and went through the rebuild. You are going to have to try this again. Can I suggest you post the first error you see here and we can try and talk you through fixing it. > I tried to copy the annotation_api.jar file from Tomcat 7.0_94 into tomcat > 7.0_45 but nothing would deploy... Why do that? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ServletRequest Obj Randomly not Processing x-www-form-urlencoded parms
On 09/12/2019 00:44, Jerry Malcolm wrote: > Mark, thank you so much for the info. I downloaded the TC source and > got everything up and running in Eclipse. After getting familiar with > the paths when it worked normally, I was able to single-step a failure. > I added a request.getParameter( "abc" ) as the first line of the JSP. > It steps into the RequestFacade then to the Catalina Request object. I > see the lazy parsing you described. It checks "parametersParsed". In > this error case, parametersParsed is already set to true, so it skips > parsing. However this is the first time here for this request, and the > parameters have not been parsed, and the getParameter returns null. > > I grepped the source tree to see if there were any other places where > parametersParsed is being set to true. The parseParameters method is > the only place. Being the first line in the JSP, I'm not aware of any > other code above the JSP that would be causing the parsing. And it > appears the only way out of the parser method is with an error condition > or successful parse, which neither appears to happen, implying it's > never being called in the error condition... leading to the possibility > that parametersParsed is somehow incorrectly set to true coming in. > > I saw some code about recycling the object instance. I haven't dug into > any of that code. Is there any possible way that a request object could > be recycled without being wiped clean first? That should not be possible. > I see the recycle method > where everything is cleaned out. But I guess it could somehow throw an > exception while cleaning it out. I realize this is a long shot. But I'm > just grasping at straws as to why the object would indicate with no > errors that the parameters had been parsed when they hadn't. You could out a try/catch around the recycle method but I have a hard time trying to thing of a scenario that would throw an Exception there. > I guess my next step is to figure out how to breakpoint when request > objects are allocated from the pool and trace it all the way up to my > JSP line. Can you give me a pointer to the class(es) that handle > request object pool mgmt? The reference chain is: Processor -> CoyoteRequest -> Request. Processors are pooled and allocated starting here: https://github.com/apache/tomcat/blob/master/java/org/apache/coyote/AbstractProtocol.java#L772 The CoyoteRequest and Response object are final fields on the Processor: https://github.com/apache/tomcat/blob/master/java/org/apache/coyote/AbstractProcessor.java#L64 The Request and Response are held as notes on the corresponding Coyote objects: https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/connector/CoyoteAdapter.java#L303 > Also, I've seen several places in the code where it says "if debug" or > something like that. I've set logging to FINEST for everything, but I > believe there are debug statements that aren't showing. Is there > another way to enable 'debug'? That should be sufficient. Can you provide a specific example? > I'm resisting setting up a full rebuild environment of TC where I can > put in println statements. But I guess if that's required, I can do > it. If you'd like to talk me out that, I'm listening That is often where I end up investigating issues such as this. I usually try and turn those println statements into useful debug logging so I need less of them next time. Issues like this can be caused if a reference to a request or response is retained longer than it should be. You can try setting: -Dorg.apache.catalina.connector.RECYCLE_FACADES=true Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: http2 async timeout setting
On 07/12/2019 03:46, Arief Hasani wrote: > Hi Chris, > Thanks for the reminder. following is the code that runs the timeout listener > on time while running on http1.1 but not on http2. tested on 9.0.29 I can reproduce this. I'm working on a fix now. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Bouncing Tomcat from HTTPD?
On 05.12.2019 19:56, Jerry Malcolm wrote: I was stuck in traffic an hour from the office when I got a text that one of my sites had gone down. If I'd been in the office, I'd try bouncing TC first just to try to get the client back online, then dig into the logs to figure out what happened. But while driving on the freeway, there's no way to access ssh into the server and key in the command to restart tomcat. httpd was working fine. It would have been nice to bring up a non-tomcat web page on my phone and press a button to cause the tomcat service to restart. I know I could probably write something in php or perl or something. But I don't want to reinvent the wheel. Are there some packages available that already do something like this? Sorry, but since using one's mobile phone while driving is known as dangerous and even against the law in many places, the security-conscious and law-abiding Tomcat support team does not think it can answer the question as phrased above. Now if you were to rephrase it, leaving off the "while driving" bit, we might tell you that some such things probably exist already, but that you would have to look at admin-like utilities or packages belonging to your OS distribution, as there is nothing in Tomcat itself which provides such a capability.(*) We may also then warn you about the security aspect of such things, because one would probably not want to allow the general public to restart one's Tomcat server through an open webpage. (*) (If there was such a capability, there would also be the interesting philosophical question of how to use it, if the Tomcat server is down). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Double Slash Support in Tomcat 9.0.27
Hi Christopher. I believe that yours is a really good explanation of why Tomcat collapses consecutive slashes in URLs. It's certainly worth a FAQ article, in case the question ever pops up again. It maybe even be worth a note somewhere in the main documentation, such as where it explains how Tomcat actually maps URLs to webapps. Except that I can't locate the documentation which specifically explains this.. Maybe this is because Tomcat normally refers to the Servlet Spec for this ? The closest I find is here : http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Naming Maybe inserting a note to the effect of 'Note: before any of the mapping below takes place, Tomcat collapses any consecutive "/" characters in the path portion of the URL to a single "/". The complete explanation is here : --> FAQ article" ' On 05.12.2019 17:13, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 12/5/19 04:55, André Warnier (tomcat/perl) wrote: Christopher, I believe that the problem of the OP is that either this filter or the application, *relies* on the fact that Tomcat would NOT collapse multiple consecutive slashes in the URL, to a single slash. That (the non-collapsing) seems to have been the case in some previous versions of Tomcat, and has apparently been changed in more recent versions of Tomcat (and probably rightly so, to adhere more strictly to the specs). Actually, it's somewhat in *violation* of the specs. But it's a generally-accepted violation because it allows security rules to actually remain sane. If you want to protect "/foo/bar.html" which maps to a file on the disk, you'll find that the filesystem collapses slashes and will load that same file regardless of how many extra slashes you put in there. "/foobar.html" is going to give you the same result. The same is true for multiple levels like "/foo/bar/bar.html". If you want to protect all files in "/foo/bar" it's not practical to add protections for "/foo/bar/" and "/foo//bar/" and "/foo///bar/" and ... you see where I'm going with this. So the server decides that slash-collapsing will allow security constraints to be more practically applied. What if we get super-spec-compliant and allow those extra slashes? Well, you'd have to get really (and, IMHO, /overly/) strict about how those slashes are treated. In Java, you'd have to do something like this : String path = ... // file-path from request String docRoot = ... // docroot base, absolute File file = new File(docRoot, path); if(!file.exists()) // return 404 if(!path.equals(file.getAbsolutePath().substring(docRoot.length())) // return 404 That last check will check to make sure that the path requested by the client *exactly equals* that of the path on the disk. That means that multiple-slashes are essentially forbidden when requesting disk-files. (It gets more fun when you are requesting a directory which has an "index file" like index.html and you have to decide whether or not it's okay to load that file automatically, even though the client didn't specifically request it.) So now we are spec-compliant. Yay! Except that all those sloppy webmasters links no longer work because they do all kinds of weird URL manipulations that don't always result in a perfectly-clean URL. So we've achieved spec-compliance and inconvenienced users. Did we really achieve anything? Those multi-slash URLs were never going to work. It is really a big deal to just ... let them work? So we collapse slashes and everything is fine. Nobody is really going to complain if /foo//bar.html and /foo/bar.html both work instead of one of them returning 404. What about resource that are *not* on a disk? Like servlets and stuff like that? Well, the servlet spec allows us to map to URL patterns of various types. Some are exact, others prefixes, etc. We can also define security constraints with the same kind of url-pattern basis. Generally, those things should agree. What happens when you introduce multiple-slashes in there? Well, nobody is ever going to map a bunch of additional slashes to make their servlets work properly. So we are back to the same problem as the on-disk-file: the multiple-slashes are essentially forbidden if we want to be super-spec-compliant. So we relax a little and take the practical approach: collapse slashes and move on with our lives. This has the added benefit of making security constraints more consistent, and fewer mistakes. And encouraging fewer security mistakes is a Good Thing. And the collapsing of multiple consecutive slashes in the URL, is probably done at such an early stage in the request processing, that it is not easy to do something to turn it off (which may or may not be spec-compliant anyway). Turning it off would be a giant mess. And yes, it needs to be doe quite early because Tomcat has to figure out which web application will be responding to the request. So it's one of the first things
