Re: Tomcat autodeploy doesn't return actual files via HTTP
05.06.2014 3:28, Christopher Schultz пишет: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am I missed something? Tomcat keep it in some cache? This is why nobody should define Context elements in server.xml: they always mess them up. In addition to what Konstantin has said, note that Tomcat is restarting the context with path [/APP] and not [/]. You have double-deployed APP.war: once as /APP and once (maybe?) as ROOT. If you can't stomach calling your WAR file ROOT.war like everybody else, then use descriptor-file-based deployment with a CATALINA_BASE/conf/[engine]/localhost/ROOT.xml descriptor. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTj7mvAAoJEBzwKT+lPKRYciAP/RxLZmt9NGIrR6+YcGS5j83p fH0rz/5VwCK8xU5i0y+UhHWf1BhaJ1JK0Fi7bcw4hvTi/h11wI7aEMCeQztyp9R9 5oDvfCTARBplNbkUS0J9eqAJvGIRxJJaI3OQfQlhOFvrQI5n5xjBHGh3FF7oX70c 5fKCgCR2YHgtzg0P9zFygP27XDi1ynhna3OG4VHLJ0LmRu/r2N+Kl+JRsgkr7NUX QYUxOlzN1sq5ROJYwZcv/7pJ8Aq1fvoRYrwj+Hdvp97h3yCql6b9EPEVVnM/mMg2 Rh5U5kbKytYXdndoy8BKDWHAaqbQ45Rs/OTsG5Qcqr3pVlaNOU1nkFioDPys809g HHa4zwWHCS5hITiQ7sgcYUxaMi6rPKw8U8DkdsJ0dFYPO2/O34qj/AJ4ryEo6RnJ Nz9rw6ZjrQPEXFxWFI5W5djIaXy+Q5m6uFIziL8NdB4XLkpe11rbiQ45lSJYeWHR crioW7VF8snLcUoja8nJtgNRbtLcZPBOAvS4ApLYAZS9rBlO09PPamvbfPJEjWV+ oZftgY//oQ6m3n/3r3CLyri/7pZ6CTclgJpQUw8vGHYMxf00YPSLAJXgRUpKTcXE DbdMdwJpsUvwPbNBUnIP4xQtnzFIk2tvxxE6uyC/NJbqOEs2dVwQMF0IVU2Uxi+t ukEh/DscpVPgumtKnifk =Hedg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Hi. Yes - problem was exactly in placing Context element in config. After removing it - all works. CATALINA_BASE/conf/[engine]/localhost/ROOT.xml // do you mean - I can set docBase=APP.war in it, and path= - and Tomcat will use it? Because I really don't like idea every time rename WAR-file in ROOT with external bash/python script, as I do it now (basically - because this must be autoDploy and war-file will have another name generated by Maven). Thanks, guys. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [Bug][Tomcat 5.5.x] Tomcat loses request parameters
Chris, Thank you for your answer. You are right about tomcat itself not being involved. I was fooled by the class ByteChunk belonging to tomcat, and didn't see that the MultipartStream belongs in fact to commons-fileupload.jar. The jbossweb-tomcat55.sar module in jboss 4.0.4.GA does come with commons-fileupload-1.2.jar. I found out that the bug I see was fixed in version 1.2.1 (issue FILEUPLOAD-144 related to issue FILEUPLOAD-135) and verified it solves my problem. Thanks again, Didier DUQUENNOY Didier, On 6/4/14, 11:30 AM, DDU DUQUENNOY Didier wrote: I think I found a problem in the way Tomcat parses the POST Http Request. It might be related to issues n°40860, 31523 and 42347 submitted to bugzilla https://issues.apache.org/bugzilla. I am running on a JBoss 4.0.4 GA server on a windows platform. I know it uses a 5.5.x tomcat, but I don't know exactly which version. Tomcat 5.5.x is no longer supported. We don't support JBoss, here, either. You'll have to get support from Red Hat at this point, or upgrade to a version of Tomcat that is supported. Symptoms : When I submit a POST request, sometimes one parameter get lost. I can tell using Eclipse's TCP/IP proxy that the value was submitted in the request. Without knowing what version of 5.5.x you are using, nobody is going to be able to tell you if a) there is a bug and b) if it was fixed in a version of Tomcat later than the one you are running. I can tell you pretty confidently that Tomcat does not lose request parameters, even old unsupported versions. ;) Analysis: The POST request looks like that and is 15kB long: -7de35e1c190e9e Content-Disposition: form-data; name=autoScroll 0,0 -7de35e1c190e9e Content-Disposition: form-data; name=principal:arbre::focused false -7de35e1c190e9e Content-Disposition: form-data; name=principal:arbre::expandedNodes It's worth pointing-out that Tomcat did not directly handle multipart requests until version 7.0.x. If you are having problems with multipart requests, the problem is likely with either /your/ (of JBoss's) multipart library or your own code. (Oddly, Tomcat does have the package-renamed classes from commons-http-upload available in the Tomcat 6 source...) Using remote debugging, I found that a MultipartStream object analyses the request using a 4KB buffer; this buffer is fed by a 8kB buffer used by a ByteChunk object. The pattern -7de35e1c190e9e is called 'boundary'. and is repeated for each field. I noted that the hex part of the boundary may not be the same length from one POST to another, I think that is why the problem does not always occur. when MultipartStream arrives at the end of its buffer and there is not enough bytes left to read the next boundary, it moves the few unread bytes to the beginning of the buffer, then loads the next chunk of data from the ByteChunk object (see MultipartStream$ItemInputStream.makeAvailable()) That class does not exist in Tomcat prior to Tomcat 6, and in Tomcat 6 does not have the makeAvailable method. In Tomcat 7, makeAvailable appears. I suspect you are using commons-http-upload, and probably a fairly old version. If this ever was a problem with commons-http-upload, I'm sure it's been fixed. In any case, you are going to have to upgrade at least commons-http-upload. I would recommend upgrading just about every component you currently have, as you are likely to be very out of date. Security patches, performance improvements, bug fixes, etc. are all available between your version and the current. - -chris Consultez nos sites internet : http://www.sofaxis.com http://www.sofcap-sofcah.com Sofaxis disclaimer : http://www.sofaxis.com/disclaimer-1.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
c:forEach doesn't support variable in Tomcat 7.0.54 while 7.0.37 supports
Hi,
In tomcat 7.0.54, the variable is not supported.
I changed the source
apache-tomcat-7.0.54/webapps/examples/jsp/tagplugin/foreach.jsp
c:set var=num value=20 /
c:forEach var=item begin=1 end={$num}
${item}
/c:forEach
Then it reports:
org.apache.jasper.JasperException: Unable to compile class for JSP
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:672)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
root cause
java.lang.NumberFormatException: For input string: {$num}
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
java.lang.Integer.parseInt(Integer.java:492)
java.lang.Integer.valueOf(Integer.java:582)
org.apache.jasper.compiler.JspUtil.coerceToInt(JspUtil.java:605)
org.apache.jasper.compiler.Generator$GenerateVisitor.convertString(Generator.java:3184)
org.apache.jasper.compiler.Generator$GenerateVisitor.evaluateAttribute(Generator.java:3001)
org.apache.jasper.compiler.Generator$GenerateVisitor.generateSetters(Generator.java:3106)
org.apache.jasper.compiler.Generator$GenerateVisitor.generateCustomStart(Generator.java:2276)
org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1768)
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1538)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377)
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2429)
org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2435)
org.apache.jasper.compiler.Node$Root.accept(Node.java:474)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377)
org.apache.jasper.compiler.Generator.generate(Generator.java:3517)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:250)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:373)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:353)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:340)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:657)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
I did same tests on Tomcat 7.0.37 and this error did not happen.
Jeff
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: c:forEach doesn't support variable in Tomcat 7.0.54 while 7.0.37 supports
2014-06-05 13:50 GMT+04:00 Jeff Cai jeff_...@symantec.com:
Hi,
In tomcat 7.0.54, the variable is not supported.
I changed the source
apache-tomcat-7.0.54/webapps/examples/jsp/tagplugin/foreach.jsp
c:set var=num value=20 /
c:forEach var=item begin=1 end={$num}
${item}
/c:forEach
Then it reports:
org.apache.jasper.JasperException: Unable to compile class for JSP
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:672)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
root cause
java.lang.NumberFormatException: For input string: {$num}
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
java.lang.Integer.parseInt(Integer.java:492)
java.lang.Integer.valueOf(Integer.java:582)
org.apache.jasper.compiler.JspUtil.coerceToInt(JspUtil.java:605)
org.apache.jasper.compiler.Generator$GenerateVisitor.convertString(Generator.java:3184)
org.apache.jasper.compiler.Generator$GenerateVisitor.evaluateAttribute(Generator.java:3001)
org.apache.jasper.compiler.Generator$GenerateVisitor.generateSetters(Generator.java:3106)
org.apache.jasper.compiler.Generator$GenerateVisitor.generateCustomStart(Generator.java:2276)
org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1768)
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1538)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377)
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2429)
org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2435)
org.apache.jasper.compiler.Node$Root.accept(Node.java:474)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377)
org.apache.jasper.compiler.Generator.generate(Generator.java:3517)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:250)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:373)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:353)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:340)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:657)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
I did same tests on Tomcat 7.0.37 and this error did not happen.
What are the first lines of your WEB-INF/web.xml file?
My guess is that you are adhering to an old version of specification
there, that does not support EL.
I can also suggest you to configure your Tomcat in strict servlet
compliance mode and see whether it complaints.
http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Specification
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: c:forEach doesn't support variable in Tomcat 7.0.54 while 7.0.37 supports
Sorry, I made a mistake in defining the variable.
Jeff
-Original Message-
From: Jeff Cai [mailto:jeff_...@symantec.com]
Sent: Thursday, June 05, 2014 5:51 PM
To: users@tomcat.apache.org
Subject: c:forEach doesn't support variable in Tomcat 7.0.54 while 7.0.37
supports
Hi,
In tomcat 7.0.54, the variable is not supported.
I changed the source
apache-tomcat-7.0.54/webapps/examples/jsp/tagplugin/foreach.jsp
c:set var=num value=20 /
c:forEach var=item begin=1 end={$num}
${item}
/c:forEach
Then it reports:
org.apache.jasper.JasperException: Unable to compile class for JSP
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:672)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
root cause
java.lang.NumberFormatException: For input string: {$num}
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
java.lang.Integer.parseInt(Integer.java:492)
java.lang.Integer.valueOf(Integer.java:582)
org.apache.jasper.compiler.JspUtil.coerceToInt(JspUtil.java:605)
org.apache.jasper.compiler.Generator$GenerateVisitor.convertString(Generator.java:3184)
org.apache.jasper.compiler.Generator$GenerateVisitor.evaluateAttribute(Generator.java:3001)
org.apache.jasper.compiler.Generator$GenerateVisitor.generateSetters(Generator.java:3106)
org.apache.jasper.compiler.Generator$GenerateVisitor.generateCustomStart(Generator.java:2276)
org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1768)
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1538)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377)
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2429)
org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2435)
org.apache.jasper.compiler.Node$Root.accept(Node.java:474)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377)
org.apache.jasper.compiler.Generator.generate(Generator.java:3517)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:250)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:373)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:353)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:340)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:657)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
I did same tests on Tomcat 7.0.37 and this error did not happen.
Jeff
-
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: Using custom classloader
2014-06-04 19:46 GMT+04:00 Don Asper don.as...@sas.com: Hi: I want my web apps running on Tomcat 7.0.35 to use a custom classloader. The reason is that I want each web app classloader instance to do some processing to set up the classpath for the web app it belongs to. I have the following questions: 1) Is org.apache.catalina.loader.WebappClassLoader a good class to derive my custom classloader from? Is it a good choice going forward for later versions of Tomcat? 2) Is there a recommended way for my custom classloader to identify which web app it belongs to? It needs to identify which web app it is for so that it will know what jars to put on its classpath. Thanks! Look at VirtualWebappLoader. Maybe it suits your needs as is. Also the same trick that it does can be performed from a Listener. There is no need to extend WebappLoader just for that. A Listener and a WebappLoader have access to Tomcat's Context class and can get the paths. The VirtualWebappLoader is not available in Tomcat 8, replaced by new Pre/Post/... resources APIs. Beware that webapp's classloader should be able to produce class path that is used by JSP compiler (Eclipse JCP or by external javac depending on how your Tomcat is configured). Tomcat WebappClassLoader has API for that. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Background thread died; no errors in log; invoking backgroundProcess via JMX has no effect
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
One of dev instances this morning is screaming because I have hundreds
of active sessions. I checked, and it looks like the background
processor thread for the context is not running, therefore no sessions
are expiring.
Tomcat 7.0.52, Debian Linux x64, Oracle Java 1.7.0_55
Here are the still-running threads:
catalina-exec-946
Attach Listener
MySQL Statement Cancellation Timer
catalina-exec-338
catalina-exec-337
catalina-exec-5
catalina-exec-4
catalina-exec-3
http-nio-127.0.0.1-8217-Acceptor-0
http-nio-127.0.0.1-8217-ClientPoller-1
http-nio-127.0.0.1-8217-ClientPoller-0
ajp-bio-8215-AsyncTimeout
ajp-bio-8215-Acceptor-0
Memcached IO over {MemcachedConnection to localhost/127.0.0.1:11211}
Abandoned connection cleanup thread
Thread-3
NioBlockingSelector.BlockPoller-1
GC Daemon
Service Thread
C2 CompilerThread1
C2 CompilerThread0
Signal Dispatcher
Finalizer
Reference Handler
main
VM Thread
GC task thread#0 (ParallelGC)
GC task thread#1 (ParallelGC)
VM Periodic Task Thread
I tried invoking backgroundProcess on my Manager bean via JMX but it
didn't seem to actually clean anything up. Is there any hope of
recovery without bouncing the web application?
Also, it would be nice to get a notification if the thread is dying
due to some exception. I searched-though catalina.out and found
nothing relevant. Any suggestions?
Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTkIp2AAoJEBzwKT+lPKRYxOUQAJVMmWhZEimBNZiSwcgP2lNA
PET0guRv9x8b9A75UcLjPU1E69OCZ1AxpsT0W8eKLhzI8ehmv/COb6JDIIW79cuL
ksOSXeFwsPQfv/f0rB2byDmIrMVBg+053PLU3v3nWWp0VnLsdrr2oGfdvyjUmdtE
WuqhmGtVqzpOuZZixq3xi2sYWwmwATA1DdsTWllat6mdbgC2289S9lv8w7a/SXO0
f3aYW+AFxnX3nPN4ldbpbrUVOUfxKHXlMdjf4Rg1Z/aTIWNrInlJSAgiUjD6hY5P
rm/F83/zbsCfm7mRDPVjw425SQ3tpYX7K6p7bSoPkCwip9brURUyuIz4aSkLv27e
fO+rgm8P3/jdUmyfh6UT+mB5li2uBS6vPHu87lrIH1c5o65x3/+S0FgNA5Q5tJNC
GYti74FNwwga+g7cOMsItnZrOExm7xnpDifctGkMV3V7S2mG66iCgDVD7vk4B8F/
tBOSR+i1OP6RMwGLbnr2OW/QFKTnksN8jBlAFF4osXIPf1QrcUwLJA7o2z3ynqlR
ykHaolvZ2HU25gieAUfKy7ZRj7dJ61aAP3Ak7Rpr9Krno0GxlKTS53JeYg1mNGsp
4goBt8jdvyMMMA8ZcV7HfAUfPAbJn/2ehmkCLBqzMu0Un3OeRADvZZrI308wTPSG
q9r0JhsDD/BZUhE47Iwj
=Az1U
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat autodeploy doesn't return actual files via HTTP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Arseny, On 6/5/14, 2:25 AM, Arseny wrote: 05.06.2014 3:28, Christopher Schultz пишет: Am I missed something? Tomcat keep it in some cache? This is why nobody should define Context elements in server.xml: they always mess them up. In addition to what Konstantin has said, note that Tomcat is restarting the context with path [/APP] and not [/]. You have double-deployed APP.war: once as /APP and once (maybe?) as ROOT. If you can't stomach calling your WAR file ROOT.war like everybody else, then use descriptor-file-based deployment with a CATALINA_BASE/conf/[engine]/localhost/ROOT.xml descriptor. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Hi. Yes - problem was exactly in placing Context element in config. After removing it - all works. CATALINA_BASE/conf/[engine]/localhost/ROOT.xml // do you mean - I can set docBase=APP.war in it, and path= - and Tomcat will use it? Because I really don't like idea every time rename WAR-file in ROOT with external bash/python script, as I do it now (basically - because this must be autoDploy and war-file will have another name generated by Maven). The file should be called ROOT.xml and should not have a path attribute *at all*. Please read the configuration guide: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTkIq/AAoJEBzwKT+lPKRYUpIP/jPDbwE3/LaoEzxTDak9DABz IEqmqokOxvHzA7PR2Ab5/vDjW9rOKlDmsJTlsK2BWdNJO5Df5/Mfy6frwS3RhxTj kzXAz9d8CHcShkDtju1NeBhxaS2McSr41He4PmkGl6WAYC8L4K1+bl9AjGlyIqJs NtMVZqbvOWxHCtxoBDKz5KgO8etOjoOfCtlAedZVpegh4u2msV5OKcp681gOcw03 hR14+YQhi2h4rKH1PB4LMdfqIKpAUNhD1emkxBdnXR+Ev9HuFJ9bnrfgxBVfn4xw c7jaKgZkWsU/in58Kqa65qAr0z0IA1mebfyYBtYBXybgee25z2aj2jYzCvegyMVc txpNJsASXJoTKiSpD8sgTgn4WC4C3kRAhILi0QBaBNlNOaI6IoFQpcu7SuQe6HmL cYRVzcBRPbc0ay8Qr38B3tJgsl+Ps+neje6t1VhXeC6lWVfyk/1mus5pkRcBm+cB k9bzwjONnqntsgf1YNwEmNbjfVpNoWEMQBNemloOKRHT7q4NmN48Zqj6H/dtD6ZS xL8lV6NSbESndCOamUpbM0EcMZd7XlAlRr4eTG+GZxvtslfMh4FhudmBMqaQqPe1 WVKDJG81eDGjXphtDEVTUS5MsOOe0F2goWsuQFcLYxr2t+7czA0wT3HXDh4QxtOn 7S9mB+GJuxnuk8lS8JdS =5F7X -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Bug][Tomcat 5.5.x] Tomcat loses request parameters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Didier, On 6/5/14, 4:10 AM, DDU DUQUENNOY Didier wrote: Chris, Thank you for your answer. You are right about tomcat itself not being involved. I was fooled by the class ByteChunk belonging to tomcat, and didn't see that the MultipartStream belongs in fact to commons-fileupload.jar. The jbossweb-tomcat55.sar module in jboss 4.0.4.GA does come with commons-fileupload-1.2.jar. I found out that the bug I see was fixed in version 1.2.1 (issue FILEUPLOAD-144 related to issue FILEUPLOAD-135) and verified it solves my problem. Glad to see it was only a point-version that you needed. Kind of a no-brainer :) I'm surprised that JBoss shipped with that broken version of commons-fileupload. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTkIr4AAoJEBzwKT+lPKRY1MgP/iiuu/72Ym/XD4j2K7n38tsK Ykum444vZkgp+XnyTMz3LDK6Y7UyHoxmJW4Yfbc0c6xI42ltrlekDjrnU7l7G+tc IXal7oSGhW8Y1jMg79TVzs/Uta9cz1U+sdSu2X/XuEWkcpJcmEH35ua+D/U4ihdL b1z7npiIHSfRrHPYvpdNxL9u5ohk98Pi1BrfIj96ADvgP4P92XPO090OBoVjTm2O q97Pz7Eer2KOApC7oDP65lnkPNzkmVVSRaminvKcSPQIVD39X7ZMoZs8pXVckm2/ qPlEb57EztI6Y4FL1rW5iQa2QqndyVGlrmKVgAyUGelQI04bDFidDKnZ8ZKXQ9tC 8rC41cr+0Iw58EGzBavwhLv6qQ+nBzviTWUUgyekUCMVhE5+SlryK+s3yZH3T6X7 R6vJSA+wrsFzwZyU3DK4plz0NCAeA5x7e5amuNHpKMwDpyaCwvxgnVxr0KjljEie i/TexZhQno7W5cWH5JhlBvGi8LYCR9aTer255U5bKmGv2EeCyqIu69sY5Ytuyf1k GaIEyTjXjHaUzw8lsA9uji0ge86JiQ3oX0ezwDiJx8donR3U/NGQEpf2ah16KcAw jXEhp2N6IH6u733FbDMS6aQdo1bBa/sg7yMndvBWnwdrTcZr462I8KTR9COTdcZE M8XmQbATZuRnzJplaSc7 =zIfA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Background thread died; no errors in log; invoking backgroundProcess via JMX has no effect
2014-06-05 19:19 GMT+04:00 Christopher Schultz ch...@christopherschultz.net:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
One of dev instances this morning is screaming because I have hundreds
of active sessions. I checked, and it looks like the background
processor thread for the context is not running, therefore no sessions
are expiring.
Tomcat 7.0.52, Debian Linux x64, Oracle Java 1.7.0_55
Here are the still-running threads:
catalina-exec-946
Attach Listener
MySQL Statement Cancellation Timer
catalina-exec-338
catalina-exec-337
catalina-exec-5
catalina-exec-4
catalina-exec-3
http-nio-127.0.0.1-8217-Acceptor-0
http-nio-127.0.0.1-8217-ClientPoller-1
http-nio-127.0.0.1-8217-ClientPoller-0
ajp-bio-8215-AsyncTimeout
ajp-bio-8215-Acceptor-0
Memcached IO over {MemcachedConnection to localhost/127.0.0.1:11211}
Abandoned connection cleanup thread
Thread-3
NioBlockingSelector.BlockPoller-1
GC Daemon
Service Thread
C2 CompilerThread1
C2 CompilerThread0
Signal Dispatcher
Finalizer
Reference Handler
main
VM Thread
GC task thread#0 (ParallelGC)
GC task thread#1 (ParallelGC)
VM Periodic Task Thread
I tried invoking backgroundProcess on my Manager bean via JMX but it
didn't seem to actually clean anything up. Is there any hope of
recovery without bouncing the web application?
Also, it would be nice to get a notification if the thread is dying
due to some exception. I searched-though catalina.out and found
nothing relevant. Any suggestions?
In general, dying threads are handled via
Thread.setUncaughtExceptionHandler(...)
and
ThreadGroup.uncaughtException(...)
The default behaviour in JRE it so log to System.err. So catalina.out
is the place where I expect it to be written.
(It is not nice as it bypasses logging framework, but that is how it
is currently).
A unusual culprit is OutOfMemoryError.
I tried invoking backgroundProcess on my Manager bean via JMX but it
didn't seem to actually clean anything up. Is there any hope of
recovery without bouncing the web application?
The background thread is started via threadStart() which is called
from ContainerBase.startInternal() / StandardContext.startInternal().
So I see no hope of recovering unless the container that owns the
thread is stopped/started. I think that by default the thread is
started by Engine, so Engine needs to be bounced here.
BTW, javadoc for ContainerBase.backgroundProcess() says This method
will be invoked inside the classloading context of this container. I
think that is not true when it is being invoked via JMX.
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 autodeploy doesn't return actual files via HTTP
05.06.2014 18:20, Christopher Schultz пишет: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The file should be called ROOT.xml and should not have a path attribute *at all*. Please read the configuration guide: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTkIq/AAoJEBzwKT+lPKRYUpIP/jPDbwE3/LaoEzxTDak9DABz IEqmqokOxvHzA7PR2Ab5/vDjW9rOKlDmsJTlsK2BWdNJO5Df5/Mfy6frwS3RhxTj kzXAz9d8CHcShkDtju1NeBhxaS2McSr41He4PmkGl6WAYC8L4K1+bl9AjGlyIqJs NtMVZqbvOWxHCtxoBDKz5KgO8etOjoOfCtlAedZVpegh4u2msV5OKcp681gOcw03 hR14+YQhi2h4rKH1PB4LMdfqIKpAUNhD1emkxBdnXR+Ev9HuFJ9bnrfgxBVfn4xw c7jaKgZkWsU/in58Kqa65qAr0z0IA1mebfyYBtYBXybgee25z2aj2jYzCvegyMVc txpNJsASXJoTKiSpD8sgTgn4WC4C3kRAhILi0QBaBNlNOaI6IoFQpcu7SuQe6HmL cYRVzcBRPbc0ay8Qr38B3tJgsl+Ps+neje6t1VhXeC6lWVfyk/1mus5pkRcBm+cB k9bzwjONnqntsgf1YNwEmNbjfVpNoWEMQBNemloOKRHT7q4NmN48Zqj6H/dtD6ZS xL8lV6NSbESndCOamUpbM0EcMZd7XlAlRr4eTG+GZxvtslfMh4FhudmBMqaQqPe1 WVKDJG81eDGjXphtDEVTUS5MsOOe0F2goWsuQFcLYxr2t+7czA0wT3HXDh4QxtOn 7S9mB+GJuxnuk8lS8JdS =5F7X -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Hi, Chris. Thanks - done it today, found answer on stackowerflow. Placed ROOT.xml in conf/Catalina/localhost/ with Context docBase=/home/user/WARNAME.war / and appBase=/some/different/dir in Host element in server.xml. Thanks for tips. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Only start manager at startup
I'm attempting to reply to a post by Mark Thomas posted on Mon, 21 Jan 2013 20:15:58 GMT at ( http://mail-archives.apache.org/mod_mbox/tomcat-users/201301.mbox/%3c50fda1fe@apache.org%3E) but I'm not sure if this is the way to do it. I'm not too keen on the whole mailing list translations to threads... Anyway I wanted to contribute a potential solution to the question of How can I configure Tomcat such that the only application to automatically be deployed/started is the application manager. It seems like the `deployIgnore` Host option can be used to exclude everything but the `manager` webapp. See the docs at ( http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Common_Attributes) Example: Host name=localhost appBase=webapps deployOnStartup=true autoDeploy=true deployIgnore=^(?!manager$).*$ ... /Host
Decoded URL set on asynchronous request
Hello, I am using this combo of components: * Apache Tomcat 8.0.8 * Apache CXF 2.7.11 * Servlet 3.0 * JAX-RS 2.0 * JDK 1.7.0_45 * Windows 7 * Chrome browser with the Advanced REST Client plug-in I developed some web services using REST that leverages CXF ability to do asynchronous methods, and under the hood, that uses Apache Tomcat. This is working fine overall, the setup and configuration are all good. There is one exception though. This is when I make a request to an async web service that uses a space in the URL, encoded to a %20. The encoding itself works fine, but internally, when Tomcat resumes the Servlet 3 continuation, it passes to some class the previously decoded path and sets it on the request URL. The request is then passed to the CXF layer, that expects a valid URL with no space and tries to instantiate a URL object from it, and fails. Here is the stack trace I got: 05-Jun-2014 12:33:37.426 SEVERE [http-apr-8080-exec-10] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [CXFServlet] in context with path [] threw exception [java.lang.RuntimeException: java.lang.IllegalArgumentException: Illegal character in path at index 134: http://127.0.0.1:8080/qlikview11/bi-service/c4aeb78f-109a-49a3-9716-10d83272a845/folders/13e5f0b4-90e2-4d11-bc5f-4f688e53bed2/Software Division/documents] with root cause java.net.URISyntaxException: Illegal character in path at index 134: http://127.0.0.1:8080/qlikview11/bi-service/c4aeb78f-109a-49a3-9716-10d83272a845/folders/13e5f0b4-90e2-4d11-bc5f-4f688e53bed2/Software Division/documents at java.net.URI$Parser.fail(URI.java:2829) at java.net.URI$Parser.checkChars(URI.java:3002) at java.net.URI$Parser.parseHierarchical(URI.java:3086) at java.net.URI$Parser.parse(URI.java:3034) at java.net.URI.init(URI.java:595) at java.net.URI.create(URI.java:857) at org.apache.cxf.transport.servlet.BaseUrlHelper.getBaseURL(BaseUrlHelper.java:49) at org.apache.cxf.transport.servlet.ServletController.getBaseURL(ServletController.java:78) at org.apache.cxf.transport.servlet.ServletController.updateDestination(ServletController.java:87) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:200) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:153) at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:211) at javax.servlet.http.HttpServlet.service(HttpServlet.java:618) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:262) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:301) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:721) at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:639) at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:605) at org.apache.catalina.core.AsyncContextImpl$1.run(AsyncContextImpl.java:208) at org.apache.catalina.core.AsyncContextImpl.doInternalDispatch(AsyncContextImpl.java:363) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:78) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:405) at org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(AbstractHttp11Processor.java:1636) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:646) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:277) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2451) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2440) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:744) The URL is perfectly encoded when it gets in the Tomcat machinery, but it gets decoded along the way, and the
Re: Background thread died; no errors in log; invoking backgroundProcess via JMX has no effect
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Konstantin,
On 6/5/14, 11:58 AM, Konstantin Kolinko wrote:
2014-06-05 19:19 GMT+04:00 Christopher Schultz
ch...@christopherschultz.net:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
All,
One of dev instances this morning is screaming because I have
hundreds of active sessions. I checked, and it looks like the
background processor thread for the context is not running,
therefore no sessions are expiring.
Tomcat 7.0.52, Debian Linux x64, Oracle Java 1.7.0_55
Here are the still-running threads:
catalina-exec-946 Attach Listener MySQL Statement
Cancellation Timer catalina-exec-338 catalina-exec-337
catalina-exec-5 catalina-exec-4 catalina-exec-3
http-nio-127.0.0.1-8217-Acceptor-0
http-nio-127.0.0.1-8217-ClientPoller-1
http-nio-127.0.0.1-8217-ClientPoller-0
ajp-bio-8215-AsyncTimeout ajp-bio-8215-Acceptor-0 Memcached
IO over {MemcachedConnection to localhost/127.0.0.1:11211}
Abandoned connection cleanup thread Thread-3
NioBlockingSelector.BlockPoller-1 GC Daemon Service Thread
C2 CompilerThread1 C2 CompilerThread0 Signal Dispatcher
Finalizer Reference Handler main VM Thread GC task
thread#0 (ParallelGC) GC task thread#1 (ParallelGC) VM
Periodic Task Thread
I tried invoking backgroundProcess on my Manager bean via JMX
but it didn't seem to actually clean anything up. Is there any
hope of recovery without bouncing the web application?
Also, it would be nice to get a notification if the thread is
dying due to some exception. I searched-though catalina.out and
found nothing relevant. Any suggestions?
In general, dying threads are handled via
Thread.setUncaughtExceptionHandler(...) and
ThreadGroup.uncaughtException(...)
The default behaviour in JRE it so log to System.err. So
catalina.out is the place where I expect it to be written.
That's what I would have thought, too. I didn't see anything,
unfortunately.
(It is not nice as it bypasses logging framework, but that is how
it is currently).
A unusual culprit is OutOfMemoryError.
I think you mean a usual culprit and I agree: this has happened in
the past where the background processor thread dies due to OOME.
I tried invoking backgroundProcess on my Manager bean via JMX
but it didn't seem to actually clean anything up. Is there any
hope of recovery without bouncing the web application?
The background thread is started via threadStart() which is called
from ContainerBase.startInternal() /
StandardContext.startInternal().
So I see no hope of recovering unless the container that owns the
thread is stopped/started. I think that by default the thread is
started by Engine, so Engine needs to be bounced here.
The JMX method backgroundProcess should call
ManagerBase.backgroundProcess which should go ahead and expire the
sessions. I don't see a reason why it wouldn't work. Unfortunately,
Tomcat's Manager wasn't in debug-log mode or I would have been able to
see what happened when I invoked backgroundProcess.
BTW, javadoc for ContainerBase.backgroundProcess() says This
method will be invoked inside the classloading context of this
container. I think that is not true when it is being invoked via
JMX.
This is ManagerBase.backgroundProcess, which does not have the same
documentation. While ContainerBase.backgroundProcess would usually
invoke ManagerBase.backgroundProcess, using JMX goes directly to
ManagerBase.
I'm still curious why invoking ManagerBase.backgroundProcess via JMX
had no effect. I'm not sure what the count and
processExpiresFrequency values were at the time, so my calls could
have been rejected due to background-processing-throttling.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTkL/LAAoJEBzwKT+lPKRYSn0P/Rs3TRlD0W7YTGuYuxIbeIoc
9CODVusNETHiUU0zrY4cJwZFXhBkfJ/ev8h9+ErEIsB854KJQNJ67F1o2iNmr3Nm
qyWHldZjaYSdns3zHKhEkhyhEutIFfM8KHMDE0azc7GtKEkKNs8en8MVuBPITTWY
JYtjh8fTaxm+rfjuLp/vRRB+Oj9GYQncuLihCvWPUzWMr+sRM0/baRaWAKP3d4M6
4EC7r2Pi3HuqMbUEYt5Vh3O3x/5BOdLsU/tu616L9fGC6aiNF2w3KUIw5pECdPS7
9vIIsXhsGQZ2+Y1TpnN/lPojItTtak6hdweMNGAKberxe816YjEdTrwkeue6MiLD
J9U8ArQLI58CJCcfM2My+dyaPea53VsBKPkYbcDpO+YM1sqko9JkJTsv1fpzeKVn
NtiCQNRq7UoaIJ7u3seTXn7piJ8ahrD+FpkLXxOiLwQ7lLNKtR4b+14smwKDrI/h
gUobA92SQNgluLetnpxAvcve1sjySSVs0RN1rpw1GPTDrh/cOWIYkdiiUzZn58lf
Ro1FyotAy9JHVDCFJpcwwIzaVty/6cJpJHI+2Ukl4aMHJRjFClioDb6Gx/wBnk7I
SNiCj1R3EKxbvrTSPruHYTSdREtQHWQYpDj6odfuNtupY65K86iS4fkNTv08CYlt
y64Igz0yrJPwqCdgAPL4
=kOau
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat autodeploy doesn't return actual files via HTTP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Arseny, On 6/5/14, 12:21 PM, Arseny wrote: 05.06.2014 18:20, Christopher Schultz пишет: The file should be called ROOT.xml and should not have a path attribute *at all*. Please read the configuration guide: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Hi, Chris. Thanks - done it today, found answer on stackowerflow. Placed ROOT.xml in conf/Catalina/localhost/ with Context docBase=/home/user/WARNAME.war / and appBase=/some/different/dir in Host element in server.xml. The Tomcat documentation clearly states that you can (and should!) do that, too. I guess having someone else do your homework for you is easier than reading documentation. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTkMBWAAoJEBzwKT+lPKRYsmcP/2KJtflh9q5652qdvdc5Uk8Y KNCYX0M5jYl0JGOYFCGvoNORrOb0rOiWN8FpW0eVdqty1ICPV1p5UrcwnfBOhIjL zqgT3vqnEqQebn/KeeOkBdCdzOmM57yMQcHOaJxtOPc3sqi0SICD4jxRc9UEPlpn 8nlHxY3hiRgBYyTEugeA0z49XD0i8AEHpxjednqOOTOVxuM5LJkHDj8rtJMtIVVX X+sw17Cx3ZzZECRWjyg46nALcAVDgiWgapTFEab9nAIe/T/NePeTfO6pSz4vOr3s 40duxxn5iDfPbQ1c6+i4wXbyTpwHZDxGBxyeJOQm5vZaz08FIGfebt8KWC926FtT k9PGgLi68PnNa9tmRVvN45qkOWfJncfD7c3WFbeXpJ9gRjz45VCHWDg5YKD85/dI z8joI3mTFs8Sqt7wcAefQdx16RU5xkrx8QMoMhmmLM86nyjiHjR25/AbhMpdZrll pgTYCyQIms9p1c5VG4/uYdg1nLtMIN2VzuCGHDyA+DLaL9d4M1KFPG6MTETNYGOs kkBfkDjdp+Q0yo7WlWmns9mZV04aS34xrJwRHOq+euBjDZqwoRoGakqjuBmRrIyk dRwaq+w5IhzjymtxisFi5y4J18Ik80rkvwGwixqbDE++0VJGODW5763GYRGa3QLt RBO7ykGGoRB/sweMMVUk =jTjP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat autodeploy doesn't return actual files via HTTP
05.06.2014 22:09, Christopher Schultz пишет: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Arseny, On 6/5/14, 12:21 PM, Arseny wrote: The Tomcat documentation clearly states that you can (and should!) do that, too. I guess having someone else do your homework for you is easier than reading documentation. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTkMBWAAoJEBzwKT+lPKRYsmcP/2KJtflh9q5652qdvdc5Uk8Y KNCYX0M5jYl0JGOYFCGvoNORrOb0rOiWN8FpW0eVdqty1ICPV1p5UrcwnfBOhIjL zqgT3vqnEqQebn/KeeOkBdCdzOmM57yMQcHOaJxtOPc3sqi0SICD4jxRc9UEPlpn 8nlHxY3hiRgBYyTEugeA0z49XD0i8AEHpxjednqOOTOVxuM5LJkHDj8rtJMtIVVX X+sw17Cx3ZzZECRWjyg46nALcAVDgiWgapTFEab9nAIe/T/NePeTfO6pSz4vOr3s 40duxxn5iDfPbQ1c6+i4wXbyTpwHZDxGBxyeJOQm5vZaz08FIGfebt8KWC926FtT k9PGgLi68PnNa9tmRVvN45qkOWfJncfD7c3WFbeXpJ9gRjz45VCHWDg5YKD85/dI z8joI3mTFs8Sqt7wcAefQdx16RU5xkrx8QMoMhmmLM86nyjiHjR25/AbhMpdZrll pgTYCyQIms9p1c5VG4/uYdg1nLtMIN2VzuCGHDyA+DLaL9d4M1KFPG6MTETNYGOs kkBfkDjdp+Q0yo7WlWmns9mZV04aS34xrJwRHOq+euBjDZqwoRoGakqjuBmRrIyk dRwaq+w5IhzjymtxisFi5y4J18Ik80rkvwGwixqbDE++0VJGODW5763GYRGa3QLt RBO7ykGGoRB/sweMMVUk =jTjP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Thanks again, Chris, for your very helpful message. I never heard earlier about documentation and never visited http://tomcat.apache.org/tomcat-7.0-doc/ before. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat autodeploy doesn't return actual files via HTTP
Arseny wrote: ... Thanks again, Chris, for your very helpful message. I never heard earlier about documentation and never visited http://tomcat.apache.org/tomcat-7.0-doc/ before. Even assuming that you don't mean documentation in general, that seems a bit hard to swallow. But I guess that when one just uses pre-packaged pre-installed versions, it might be possible. But a thought just strikes me : maybe you never heard of Google either ? If so, here is a tip : http://lmgtfy.com/?q=tomcat+documentation Amazing, he ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Background thread died; no errors in log; invoking backgroundProcess via JMX has no effect
2014-06-05 23:06 GMT+04:00 Christopher Schultz ch...@christopherschultz.net:
On 6/5/14, 11:58 AM, Konstantin Kolinko wrote:
2014-06-05 19:19 GMT+04:00 Christopher Schultz
ch...@christopherschultz.net:
I tried invoking backgroundProcess on my Manager bean via JMX
but it didn't seem to actually clean anything up. Is there any
hope of recovery without bouncing the web application?
Also, it would be nice to get a notification if the thread is
dying due to some exception. I searched-though catalina.out and
found nothing relevant. Any suggestions?
In general, dying threads are handled via
Thread.setUncaughtExceptionHandler(...) and
ThreadGroup.uncaughtException(...)
The default behaviour in JRE it so log to System.err. So
catalina.out is the place where I expect it to be written.
That's what I would have thought, too. I didn't see anything,
unfortunately.
(It is not nice as it bypasses logging framework, but that is how
it is currently).
A unusual culprit is OutOfMemoryError.
I think you mean a usual culprit and I agree: this has happened in
the past where the background processor thread dies due to OOME.
Yes, a typo. I meant a usual one.
I tried invoking backgroundProcess on my Manager bean via JMX
but it didn't seem to actually clean anything up. Is there any
hope of recovery without bouncing the web application?
The background thread is started via threadStart() which is called
from ContainerBase.startInternal() /
StandardContext.startInternal().
So I see no hope of recovering unless the container that owns the
thread is stopped/started. I think that by default the thread is
started by Engine, so Engine needs to be bounced here.
The JMX method backgroundProcess should call
ManagerBase.backgroundProcess which should go ahead and expire the
sessions. I don't see a reason why it wouldn't work. Unfortunately,
Tomcat's Manager wasn't in debug-log mode or I would have been able to
see what happened when I invoked backgroundProcess.
1. If you have Manager webapp installed, it has API to expire sessions
(on the list page in HTML gui)
2. I think logging level can be manipulated via JMX.
BTW, javadoc for ContainerBase.backgroundProcess() says This
method will be invoked inside the classloading context of this
container. I think that is not true when it is being invoked via
JMX.
This is ManagerBase.backgroundProcess, which does not have the same
documentation. While ContainerBase.backgroundProcess would usually
invoke ManagerBase.backgroundProcess, using JMX goes directly to
ManagerBase.
OK.
I'm still curious why invoking ManagerBase.backgroundProcess via JMX
had no effect. I'm not sure what the count and
processExpiresFrequency values were at the time, so my calls could
have been rejected due to background-processing-throttling.
//ManagerBase.java
@Override
public void backgroundProcess() {
count = (count + 1) % processExpiresFrequency;
if (count == 0)
processExpires();
}
processExpiresFrequency should be readable via JMX.
Default is '6', so you have to call the method 6 times in a row.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Background thread died; no errors in log; invoking backgroundProcess via JMX has no effect
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Konstantin,
On 6/5/14, 4:27 PM, Konstantin Kolinko wrote:
2014-06-05 23:06 GMT+04:00 Christopher Schultz
ch...@christopherschultz.net:
On 6/5/14, 11:58 AM, Konstantin Kolinko wrote:
2014-06-05 19:19 GMT+04:00 Christopher Schultz
ch...@christopherschultz.net:
I tried invoking backgroundProcess on my Manager bean via
JMX but it didn't seem to actually clean anything up. Is
there any hope of recovery without bouncing the web
application?
Also, it would be nice to get a notification if the thread
is dying due to some exception. I searched-though
catalina.out and found nothing relevant. Any suggestions?
In general, dying threads are handled via
Thread.setUncaughtExceptionHandler(...) and
ThreadGroup.uncaughtException(...)
The default behaviour in JRE it so log to System.err. So
catalina.out is the place where I expect it to be written.
That's what I would have thought, too. I didn't see anything,
unfortunately.
(It is not nice as it bypasses logging framework, but that is
how it is currently).
A unusual culprit is OutOfMemoryError.
I think you mean a usual culprit and I agree: this has happened
in the past where the background processor thread dies due to
OOME.
Yes, a typo. I meant a usual one.
I tried invoking backgroundProcess on my Manager bean via
JMX but it didn't seem to actually clean anything up. Is
there any hope of recovery without bouncing the web
application?
The background thread is started via threadStart() which is
called from ContainerBase.startInternal() /
StandardContext.startInternal().
So I see no hope of recovering unless the container that owns
the thread is stopped/started. I think that by default the
thread is started by Engine, so Engine needs to be bounced
here.
The JMX method backgroundProcess should call
ManagerBase.backgroundProcess which should go ahead and expire
the sessions. I don't see a reason why it wouldn't work.
Unfortunately, Tomcat's Manager wasn't in debug-log mode or I
would have been able to see what happened when I invoked
backgroundProcess.
1. If you have Manager webapp installed, it has API to expire
sessions (on the list page in HTML gui)
2. I think logging level can be manipulated via JMX.
I hadn't thought of that. Next time. ;)
BTW, javadoc for ContainerBase.backgroundProcess() says This
method will be invoked inside the classloading context of this
container. I think that is not true when it is being invoked
via JMX.
This is ManagerBase.backgroundProcess, which does not have the
same documentation. While ContainerBase.backgroundProcess would
usually invoke ManagerBase.backgroundProcess, using JMX goes
directly to ManagerBase.
OK.
I'm still curious why invoking ManagerBase.backgroundProcess via
JMX had no effect. I'm not sure what the count and
processExpiresFrequency values were at the time, so my calls
could have been rejected due to
background-processing-throttling.
//ManagerBase.java @Override public void backgroundProcess() {
count = (count + 1) % processExpiresFrequency; if (count == 0)
processExpires(); }
processExpiresFrequency should be readable via JMX.
Default is '6', so you have to call the method 6 times in a row.
Aah. I gave up after 3. Next time.
Thanks for the info!
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTkOEWAAoJEBzwKT+lPKRY9hwP/Azf+FdBNpEl/V29SjuVfAb/
GTkEwzcVyxFh0uzr1wydcjdw8vE/SeVYcL0++dWmjzV6qGPeVLY0/wbrASBfJckc
Cka8gbLpSnIaVkrGqEAqWvfisSXYY2UGpCh2raOzgRW8/kqKcwriNrxRyZ7vPXXo
v4Ql+J4mjBC+XN4RRqHnz//l0bRBuwYGUgfeew7Tv5hO32PfGV2GS6FtgsbceIP7
GDRpqFoBo9xQtmgYHvHIVYrRD7zSBFcf72YZdY23PIlQum6TdvxWjkt0KipNrRE8
N7mDBprddiuRv1q6vNjWJbkz+y+YROd4PlHpK/sCxhdQMfvpl4SpNXp2Uo0b6cBB
KiFjJ6i9HUcEbaHrRZXCS+UoOxBOhQM/WBRtPXv/Vy+k7hIyjtfs1QCojrwnQQcl
EMff7iDdukk+m2FlnK3SdbxJALGtVh1Y+Q3eYa+X3IqBoz7/RQDt1tBUjpm4eKkF
G+cg7/+JubJJh+2TMOHzi7YFsBo978TMMO3rmu+Bl3E4YHayzt0RMfde2V0Dj4jD
WJCQOFz/JYHRjZoeY/lJSx0Y9kydfNeqF/aQ5hlF1+c2PKVYVkwp5NG5H48yXjpo
E3HcDV0nSV69VmbWQKiZpGn74B5J9tHTLQ7KYFJRH0BpyOk+QZc0Zzh2zTtAnbyq
tRA2omkbjAifP0PA0IMg
=jS15
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
