Re: mod_jk resubmitting request to Tomcat
On Sat, Jun 4, 2016 at 12:00 PM, Jerry Malcolm wrote: > I am calling a JSP to start a fairly long-running process in Tomcat. I'm > not using the page response data. The JSP is simply a way to initiate the > process. The JSP simply returns "OK" or "RC=". However, mod_jk gets > impatient, and after about 5 minutes, it decides to send the request to > Tomcat again, which kicks off another instance of the back-end process > (obviously not what I want). Following is from the mod_jk log: > > >>> can't receive the response message from tomcat, network problems or > tomcat is down (127.0.0.1:8009), err=-60 > >>> Tomcat is down or refused connection. No response has been sent to the > client (yet) > >>> receiving from tomcat failed, recoverable operation attempt=0 > >>> sending request to tomcat failed, recoverable operation attempt=1 > > How can I tell mod_jk to be more patient for this request and not to > resubmit it? > you probably have the reply_timeout on the worker set too low. https://tomcat.apache.org/connectors-doc/common_howto/timeouts.html -Tony > Thanks. > > Jerry > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
mod_jk resubmitting request to Tomcat
I am calling a JSP to start a fairly long-running process in Tomcat. I'm not using the page response data. The JSP is simply a way to initiate the process. The JSP simply returns "OK" or "RC=". However, mod_jk gets impatient, and after about 5 minutes, it decides to send the request to Tomcat again, which kicks off another instance of the back-end process (obviously not what I want). Following is from the mod_jk log: >>> can't receive the response message from tomcat, network problems or tomcat is down (127.0.0.1:8009), err=-60 >>> Tomcat is down or refused connection. No response has been sent to the client (yet) >>> receiving from tomcat failed, recoverable operation attempt=0 >>> sending request to tomcat failed, recoverable operation attempt=1 How can I tell mod_jk to be more patient for this request and not to resubmit it? Thanks. Jerry - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7.0.40 - http sessions not expiring
Hi Chris, Thanks for the help. I don't see any OOME around this time. Before restarting I collected the heap and thread dumps. Looking at one of the thread dumps, I see the ContainerBackgroundProcessor (below). So looks like that thread didn't die entirely, may be it just stopped working ? *"ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon prio=10 tid=0x7fd000a5d800 nid=0x9be5 waiting on condition [0x7fcfc4955000]* * java.lang.Thread.State: TIMED_WAITING (sleeping)* * at java.lang.Thread.sleep(Native Method)* * at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1508)* * at java.lang.Thread.run(Thread.java:745)* * Locked ownable synchronizers:* * - None* - I have attached a screenshot of the StandardManager runtime attributes from the heapdump. Is there anything anyone can see wrong here? - Is there anything else I can look for in the heapdump and threaddump? [image: Inline image 1] thanks, Stephen On Fri, Jun 3, 2016 at 5:57 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Stephen, > > On 6/3/16 8:47 PM, Stephen Bhadran wrote: > > *Linux version:* 2.6.32-279.5.2.el6.x86_64 ( > > mockbu...@c6b10.bsys.dev.centos.org) (gcc version 4.4.6 20120305 > > (Red Hat 4.4.6-4) (GCC) ) *Java Version: *1.7.0_55 *Tomcat > > Version: *7.0.40 *Session Timeout: *30 minutes > > > > Hi, Two of our servers reached max heap and we had to restart to > > resolve the issue. > > > > In troubleshooting, we noticed Http Sessions had stopped expiring > > 05/12th and reached 25K over a period of 11 days. I noticed the > > same behavior in both servers, the session expiration seem to have > > stopped on both of them around the same time. I'm saying this > > because from looking at the monitoring graphs (NewRelic) I notice > > the http sessions starting to climb on both servers around the same > > time frame. > > > > I am thinking, the issue could be two folds: #1 - The session > > expiration stopped working -OR #2 - The sessions themselves were > > created with TTLs way into the future > > > > I suspected #1. I looked that tomcat 7.0.40 source code, extracted > > all session/manager error messages and searched for them in the > > logs and didn't find any hits. I was hoping to find something about > > "Session expiration stopped working", but didn't find any. > > > > Can you please advise how to troubleshoot this issue? I'd very > > much appreciate the help. > > Were there any errors around the 12th? I've found that in rare cases, > the server hits an OOME while the BackgroundProcessor thread is > running, which kills the BackgroundProcessor. > > Guess which thread is responsible for triggering the session-cleaner? > > If the BackgroundProcessor died, it should have dumped an error to a > log file. As I said, it's pretty rare, but it does happen and then > it's only a matter of time before your sessions bust your heap. > > You can manually-trigger the session-cleaner via JMX of you absolutely > have to, but I'd personally prefer to bounce a Tomcat instance in that > case. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJXUid5AAoJEBzwKT+lPKRYJfYQAKA2ditjB7B2vLbm0po83Tr0 > YD2EjqLBrF4O/3Wu6enIDRAQEIGgXmTr2bgPlMvu+6aoDopiCSKltRxWQFlTMyIP > 8ura/0YlS5sX3yGPPKN5nrZnOz2dvrgPncHLNVfuM9BEm+8QZPeKNZVDhMH53m1v > 4YcLCM5IjswAS4FrVeG9A0gcZplBd53WUuypnRYQMUcS1sACdItoZ3TLAwb/WBg/ > T9yoyftEXJVtP6lovkaWka3yw3v382P6HmSV6/TtCWjogB/tBdCsEPmGEQ0j7k8y > 9dLmmTBawDdckaxiGf1M1M/5R+f7XqU4e02Dnhk9v4umysmu5EH+VQFO4kfi5qX+ > DvaoS13lluyN1LGMyuwHkYFHXxlgZhR/XAW9Cn/0D/NDCQks6lHG9Sby+T/kvLSO > YNSBV78SX9wsJ/fH9MxrcTarxyUYsxnHdNkcarkmcrQIkhda/vBXQobXpYVL9poR > HmxNGNOujCTojqPJzlpgAaUVUq6pEUcN3u1vkCqXNQGVo983PHz2JhfEBGYihKBk > icbuFxfIy2Dv6KwuPPMV9Y7nVRNVBrVEpieZuAc7Sj9/U3kUgPUznUSbRFUCnGd1 > YI/kq9rn/qj/aqhaJdMF0Ci4+ieJMorKNUE1PWOjbnya8XoyBxXfPd5iV6n7elEw > V6qNyO6n46isrAiVEu5c > =MyIX > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Custom Authenticator
Am Mittwoch, den 01.06.2016, 09:29 -0400 schrieb Christopher Schultz: > Thomas, > > On 6/1/16 7:15 AM, Thomas Meyer wrote: > > > > Hi, > > > > How do I get a custom mapping set in > > ContextConfig.setCustomAuthenticators? ( > > https://tomcat.apache.org/tomcat-8.0-doc/api/org/apache/catalina/st > > art > up/ContextConfig.html#setCustomAuthenticators(java.util.Map) > > > > > > > ) > > > > > > I want to add a custom mapping for lets say BEARER to a my > > Authenticator. I searched the source code but nobody seems to call > > this method. So how and where should this map be configured? > Do you mean that you want to replace FORM or CLIENT-CERT in web.xml > with BEARER and have it use your authenticator? > > Would you be okay if you just ignored the and installed > your own authenticator? Because you can do that just by registering > your CustomAuthenticatorValve in your valve chain for your > application. Hi, I came up with this solution: 1.) use custom host implementation in conf/server.xml in add className="de.m3y3r.catalina.core.CustomStandardHost" attribute 2.) webapp's web.xml - add login-config BEARER OAuthRealm Apply security-constraint as usual. use role "**" if you just want authentication. 3.) in webapp's context.xml define a suitable realm https://localhost:8080/path/to/endpoint"; clientId="username" clientSecret="password"/> Code is here: https://github.com/thomasmey/BearerTokenAuthenticator Feedback is welcome. with kind regard Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: memory-leak in org.apache.jasper.compiler.Mark|Node$TemplateText
thanks for help - but, are you really sure? if i - set development=false - delete everything within work subdir to force recompile of every jsp then for me, the initial crawl makes jvm consume the same amount of memory regardless development true or false - and thats what i'm wondering about. indeed, with development=false, subsequent jsp access does not consume memory as there is no recompile. this is why this param helps workarounding the problem, but it does not make the memory consumption of the initial compile run go away and i`m curious, why the initial compile run permanently leaves millions of referenced objects in memory. is this to be expected? regards roland Am 03.06.2016, 21:43, Mark Thomas schrieb: On 03/06/2016 17:14, devz...@web.de wrote: You are NOT observing a memory leak. > Regardless we have set "development" to true or false in > conf/web.xml, , whenever i recursively crawl our website with wget > (cleaning work dir before to make sure each page is being compiled > again), i can easily trigger an out-of-memory condition in the JVM. > When development=false, then i cannot trigger it when i did > re-compile every jsp in several steps (with restarting tomcat). You are not correctly configuring development to false. I have confirmed the expected behaviour with a profiler when development is set to false. > With VisualVM (part of jdk) i found that after wget -r crawl, there > are 13 million instances of the following classes: > > org.apache.jasper.compiler.Mark > org.apache.jasper.compiler.Node$TemplateText That will only happen if development is true. > My understanding from a compile run is, that it`s something which is > done once and then it`s ready and done and nothing is left in > memory. That is not the case when development is false. The results of the parsing are retaining in memory to aid the generation of useful error reports. > We have some ten-thousands JSPs, i`m not sure how many being crawled > with wget, but i don`t get the point why i see ressources being > allocated from org.apache.jasper.compiler and not being freed after > compile run. > > Does anybody have a clue ? Is this to be expected, and if yes - why > ? 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
