Re: From HTTP to HTTPS request.getHeader(referer)
Hi, Christopher Schultz wrote: If you want to switch protocols I don't think I want that... but maybe I do not understand properly what you mean... For the webapp I've been considering in that thread, I would like Tomcat to serve pages only via HTTPS. I do not want some pages to be served via HTTP and some others to be served via HTTPS. I don't know if it clarifies my point... Have you had a little time to have a look at the configuration files I posted yesterday (complete server.xml and excerpt from the webapp's web.xml)? 1) In web.xml, I set the CONFIDENTIAL security constraint which, as far as I understood, imposes the use of the HTTPS protocol to serve the JSP pages of the webapp. 2) Ideally, I would like the webapp users to enter HTTPS URLs in their browser URL bar/directly click URLs like https://host/webapp/a-page.jsp. But I also would like them to be able to enter HTTP URLs like http://host/webapp/a-page.jsp which are, to my understanding automatically transformed into https://host/webapp/a-page.jsp thanks to the server.xml configuration line: Connector port=80 enableLookups=false redirectPort=443/ I realize I do not know what happens to the request in that case (http://host/webapp/a-page.jsp). Is it encoded or not? Terence M. Bandoian wrote: I'm not sure how you're using it but it's worth pointing out that response.sendRedirect Sends a temporary redirect response to the client... The client (browser) must then send another request to the server before any additional processing takes place. In contrast, pageContext.forward takes place entirely on the server. I didn't know that. I thought there was one HTTP(S) request and one HTTP(S) response only. How can the mechanism you describe above affect the use of HTTPS for a webapp with the CONFIDENTIAL security constraint on a standalone Tomcat server? I'm using sendRedirect() in a very straightforward way I think. I use some sort of pipelines for a subset S of JSPs in the webapp: 1) Given a JSP s in S, it contains a form with an action attribute mapped via web.xml to a servlet L. 2) The servlet L implements either a doPost() or (rarely) a doGet() method. 3) Given what was submitted via the form, work is performed in the servlet. 4) When the servlet work is done and depending on the result (success 1, ..., success n / error 1, ..., error n), the servlet redirects towards the next JSP using the method sendRedirect(). Is there a temporary redirect response to the client in that case? Is this behavior documented somewhere? I could totally benefit from a good documentation... Best regards. -- View this message in context: http://tomcat.10.x6.nabble.com/From-HTTP-to-HTTPS-request-getHeader-referer-tp5024782p5024951.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Separation of CATALINA_HOME and CATALINA_BASE
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: 03 November 2014 20:51 To: Tomcat Users List Subject: Re: Separation of CATALINA_HOME and CATALINA_BASE On 03/11/2014 19:38, vince.w...@thomsonreuters.com wrote: snip/ Yes, I've read RUNNING.TXT and I'm left wondering why do I have a catalina class not found if all the tomcat jar files are in CATALINA_HOME/lib Because you are trying to configure a listener that doesn't exist in the version of Tomcat you are trying to use. You can't take a config from one version of Tomcat, apply it to an earlier version and expect it to work. Mark Thank you. I wrongly assumed config would be compatible across different releases of Tomcat 8. Using CATALINA_BASE: C:\tomcat8catalina_base Using CATALINA_HOME: C:\tomcat809 Using CATALINA_TMPDIR: C:\tomcat8catalina_base\temp Using JRE_HOME:C:\jdk1.7.0_55 Using CLASSPATH: C:\tomcat809\bin\bootstrap.jar;C:\tomcat8catalina_base\bin\tomcat- juli.jar Listening for transport dt_shmem at address: tomcat_shared_memory_id 03-Nov-2014 17:45:50.410 SEVERE [main] org.apache.tomcat.util.digester.Digester.startElement Begin event threw exception java.lang.ClassNotFoundException: org.apache.catalina.startup.VersionLoggerListener All these experiments are done running Tomcat under NetBeans so perhaps part of my issue is with NetBeans. The CLASSPATH shown above is a bit on the short side, is it meant to be so short ? Yes. 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: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Neven, On 11/3/14 6:42 PM, Neven Cvetkovic wrote: Vince, the current configuration works great: 1) If you are a newbie administrator you are going to use easy-to-use-newbie-friendly configuration. It will get you started, it will get your application working, etc... Great starting point. 2) If you are developer (newbie or expert) and using IDE (Eclipse, Netbeans, IntelliJ) - you are going to use out-of-box tomcat configuration. Single Tomcat instance, no-split configuration. 3) If you are administrator that is upgrading Tomcat, you will just create a process to configure your instance with new Tomcat binaries and copy over the configuration file (most of the stuff is backwards compatible in server.xml within the point-version) + add any shared libraries to new tomcat/lib folder (JDBC drivers, etc...). Again, single-tomcat instance, no-split configuration necessary. Although, may people do like to split for easier upgrades and separation of concerns. 4) If you are administrator that is managing multi-instance environment, you can still get away with copying standard out-of-box Tomcat directory over and over again, for each instance separately. The hassle would be to do the upgrades on many instances. That's why we have CATALINA_HOME for shared stuff (binaries+libraries) and CATALINA_BASE for instance-specific configuration. And in this case you would know about the split directory setup option and would research how to do that effectively. My question is - why do you use CATALINA_BASE if you are using IDE (Netbeans)? If you are developer, there is no need to use split configuration. SLIGHTLY-OFFTOPIC: Although, I would love to see out-of-box setup for additional shared-lib folder, something other than TOMCAT/lib with Tomcat default libraries. Essentially, I would love to separate my customer shared libraries from Tomcat default libraries. I guess - question would be where are CATALINA_HOME/lib JAR files being loaded from? Can we add another directory to scan for libraries to be loaded? Is that configurable? I'm not sure about that, but if the Windows installer could ask the user if they want a unified versus split configuration, that might be nice. The installer could then ask for the location of CATALINA_BASE and offer to create it if necessary. That way, users performing upgrades could specify their existing CATALINA_BASE during installation and not have to go back and re-configure the Windows Service. It would also allow newbies to know that there is an advanced configuration and perhaps go learn about it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUWPLHAAoJEBzwKT+lPKRYNmsP/3RR7xpKGttbs7iDwAzf29qu EwmQTJd063qcKiDABAkyFfwMy1IQL2/HMM30SL8XFGKhC0kFJZsr/r6kd/Y60cyN Q7+7uDNmvTtDvI4/3j2lTZ4e6gXo7UwTECxYcXinbM+eFnwZFH3xy/u1uC7vv4jV gcJ6TFZInqbArwJGDiCuKsaoPGZe1uqEGhCLJjSAz0Yx3gMZBkhi3wQHIGsZkknA Y9gVw0XAr3oAZHVZMf0bwP+ASH1RwwmRfn5dTgyxnQlAHiJCuA5AKdPtS0L/mkKj m0qk4MLx5+yWJw+Zll0qNkjgCVbZZ44qaDPwQiG2IFQjSj2dRU7a8PTtDjkPtklw SUZN1gqEdozuQPqivePN/QEZWqsnSGUtwRQvfr1cmpi4zcucgS7nyK+HE9ySX9/W H8y61BsTWRV/HHd/d+72/ZxQWH6qR0RKkRQDdwi116bdYb+gRp5B94l0EQ3MHMvB UemvCqvG6sxlB4gKdLjBbFYkn8YUjwRTSrQFbOmpGykW3hAbSnC1qHuwUPQ/ZM2T dqv1cnUn/BCGRUD+0xmiU/8UXim3DAxqaRknwfsWj5Lc5bOkdzWJKvg36fKHI/WD SB7Pcg9vyaV2NFFZh5kJU1xU4DhJ+ZWHqAOW+zzmB0wXqo+mlafkn3YidtMWRTYJ CKZvkdKcmf/6rIiIwRMJ =w+SD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Neven,
On 11/3/14 6:58 PM, Neven Cvetkovic wrote:
On Mon, Nov 3, 2014 at 6:42 PM, Neven Cvetkovic
neven.cvetko...@gmail.com wrote:
SLIGHTLY-OFFTOPIC:
Although, I would love to see out-of-box setup for additional
shared-lib folder, something other than TOMCAT/lib with Tomcat
default libraries. Essentially, I would love to separate my
customer shared libraries from Tomcat default libraries. I guess
- question would be where are CATALINA_HOME/lib JAR files being
loaded from? Can we add another directory to scan for libraries
to be loaded? Is that configurable?
I guess, it's easy to add new directories to
TOMCAT/conf/catalina.properties file:
common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
to now read:
common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,${catalina.base}/shared,${catalina.base}/shared/*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar
Or
just use shared.loader, which is I think what you're asking for.
It's blank in a default configuration.
What are you thoughts? Would it make sense to keep a separate
directory for shared libraries? Should we make it default - to
encourage others to create a directory if they want to.
- -1
This is confusing and would be surprising if you hadn't intended to
use this. The shared loader was disabled by default because nobody
could figure out what the heck it was for and basically continually
broke their own configurations using it. So, now, everything goes into
either lib/ or the web application's WEB-INF/lib and everyone seems to
be happy. One can always re-enable the shared loader if you know it
exists, in which case you probably know what it's for and why you'd
use it. (Hint: use of the shared loader almost never makes any sense).
Default behaviour for
org.apache.catalina.startup.ClassLoaderFactory is to validate if
the file exists/isDirectory/isReadable? That might confuse
beginners with a Warning ...
I guess Tomcat philosophy is to keep it simple, and extensible - so
experts that need to customize things they can, and it is simple
and not confusing for beginners.
What are your thoughts?
I like the current default configuration but I'm willing to entertain
other ideas. I just don't like this one in particular (default to
split configuration).
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUWPO/AAoJEBzwKT+lPKRYhzwP/21gMhPUd7yVXzk/ImpkZMjr
chWiBFFXl8NA76onaHSvFEIAbwSYbpTjboCd2QdDu0qIFi/O4cyirnYhHRfPISGb
P+mHu0vg+9Ppze+uk5liQiULutEXdeqt97Sfom/I0j+GJZ2UxqvTGVIrwAa+63Op
7f8yg+wTXWQquz7vTkNwp/fGRBB5EB6ZJetffc0gPrsCG4L8muOobVhgd7wK9Yxf
wkWBSXVYTwgOIzlgdYBV2F92EiDMfPihOHQ+jgDHnxebOFc9jCppYcKa96c1LL36
7bTgdSvWNbxJXODCEBVUkoe2rbAr2u7/ZsRWiSOJlfPEBal9Rno/n3C/O6PAhA8J
xGB9ixtFyry9Z9V5XY+aUgI0+DKgSoddo2REtcuK0/X+mpyfUXB5A2GqNRaWxXSo
3+hHxfuJw8kLBjaWGswqgMhF0XBS07pNr87QDxldaROeg4Ty0apr6NRdkdSJ8eGE
+lvWIC+2dN7ufPo7tt3S0+cCDngvtpPMBdHtp7L1PplN9ilTBmxSYRcl/ZOMaE7J
hwSSsYFWRz/40EcTvkO6FCtiuWFW8490pqUuTvfz+ImO+rzSlAlJ2T0vq63Bbfjp
EwkVMlV1V421cDUI7JhyVsg1qw6lcsrY3wxPxXUpyGWMAUoQaScCcxGc1mN35D2/
5ufXCKK6w1sv89jfm5jg
=LSsh
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: From HTTP to HTTPS request.getHeader(referer)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Léa, On 11/4/14 5:46 AM, Léa Massiot wrote: Christopher Schultz wrote: If you want to switch protocols I don't think I want that... but maybe I do not understand properly what you mean... For the webapp I've been considering in that thread, I would like Tomcat to serve pages only via HTTPS. I do not want some pages to be served via HTTP and some others to be served via HTTPS. I don't know if it clarifies my point... If you are already in HTTPS protocol and don't want to switch, then you shouldn't have to specify the protocol in the redirect. Have you had a little time to have a look at the configuration files I posted yesterday (complete server.xml and excerpt from the webapp's web.xml)? Yes, they don't really help in any way because they don't describe use cases. You didn't provide anything like I want X, I tried Y, and Z happened so it's hard to help you out. 1) In web.xml, I set the CONFIDENTIAL security constraint which, as far as I understood, imposes the use of the HTTPS protocol to serve the JSP pages of the webapp. Yes. Tomcat should therefore handle redirecting the user from HTTP to HTTPS on the first request. 2) Ideally, I would like the webapp users to enter HTTPS URLs in their browser URL bar/directly click URLs like https://host/webapp/a-page.jsp. But I also would like them to be able to enter HTTP URLs like http://host/webapp/a-page.jsp which are, to my understanding automatically transformed into https://host/webapp/a-page.jsp thanks to the server.xml configuration line: Connector port=80 enableLookups=false redirectPort=443/ I realize I do not know what happens to the request in that case (http://host/webapp/a-page.jsp). Is it encoded or not? Tomcat should redirect the user to https://host/webapp/a-page.jsp. Your JSP code will not run in this case until the HTTPS request has been received. Look at your access log to file out what's going on when you request an http:// URL. Terence M. Bandoian wrote: I'm not sure how you're using it but it's worth pointing out that response.sendRedirect Sends a temporary redirect response to the client... The client (browser) must then send another request to the server before any additional processing takes place. In contrast, pageContext.forward takes place entirely on the server. I didn't know that. I thought there was one HTTP(S) request and one HTTP(S) response only. How can the mechanism you describe above affect the use of HTTPS for a webapp with the CONFIDENTIAL security constraint on a standalone Tomcat server? Read about what an HTTP residrect does. I'm using sendRedirect() in a very straightforward way I think. +1 I use some sort of pipelines for a subset S of JSPs in the webapp: 1) Given a JSP s in S, it contains a form with an action attribute mapped via web.xml to a servlet L. 2) The servlet L implements either a doPost() or (rarely) a doGet() method. 3) Given what was submitted via the form, work is performed in the servlet. 4) When the servlet work is done and depending on the result (success 1, ..., success n / error 1, ..., error n), the servlet redirects towards the next JSP using the method sendRedirect(). I would say this is a pretty standard way to do things: the form-handler should do its job and then *redirect* (not forward) to another page. Otherwise, re-loading the next page on the client will re-submit the form, which is rarely what you want to have happen. Is there a temporary redirect response to the client in that case? Is this behavior documented somewhere? I could totally benefit from a good documentation... A temporary redirect is a term right from the HTTP spec. It means a 302 response code which has a special meaning to clients. Google for http status codes and read about them all. It's good to know these things. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUWPTvAAoJEBzwKT+lPKRYzBUQAL409gE2n0wI8t3B5JBdvXoB y6RjmdT2mD4WWVlsqoDmzXP6M3ziVDifsn+oj9bggHGtRaA8RKCXVGvFHrq+WQ4b j2r8hdGoUkbPBOY68m0F+IFOceTn3UWw84kjySfLtfyqldkvoBoRXBPTKq4aviok eMMnRmCr6XhwKfMY9lVaqFJQ+XwLViij4bqvu/oAmS71jzruBTVv1ZhYMGhICBcq 10jA9ow0XhyHcEcgwZAFJ0U8xqKdNHYWgvjj83TY6lkih0Gvo/pjEWYMFfJN4aR1 U8feGtKtiy5H7JQwlA3x7vDniqzop8dnyZM83pEtsIUV+GKihXVp+n0glSt2ryPW c5fUF58JtpRYk/3k/3vvwl4NU+FmcyXLjDl1EgUD8icDGH0lUZH+tYvHZCR02h1/ v8fn+d4WUdpDUtIkJSdEDSCbVhdmTSZdxPcbRby1GwZWr82wWBM3lWEXSSwB7+vq Cnd895ithqp42vWpIIzs5Won9DdvZ9EgPfBBsEtA7+VGiz+N9wXVQg0TZhvj9JxK 3foXkmGZEZE/xHLs822UqZ9YAiCkbQmfQbZARSppkBBWqhuXdG9opaMvOMwdFJaY 1SutJpFczUqaxDrvq8HSaGKVA9sYxc1phXM3VkvUkvGyXddFQdLkkU2C44NOjSpV DMQNpgPedI0rQRZSCuoO =6hs8 -END PGP SIGNATURE- -
Re: Separation of CATALINA_HOME and CATALINA_BASE
On Tue, Nov 4, 2014 at 9:37 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Neven, On 11/3/14 6:42 PM, Neven Cvetkovic wrote: Vince, the current configuration works great: SLIGHTLY-OFFTOPIC: Although, I would love to see out-of-box setup for additional shared-lib folder, something other than TOMCAT/lib with Tomcat default libraries. Essentially, I would love to separate my customer shared libraries from Tomcat default libraries. I guess - question would be where are CATALINA_HOME/lib JAR files being loaded from? Can we add another directory to scan for libraries to be loaded? Is that configurable? I'm not sure about that, but if the Windows installer could ask the user if they want a unified versus split configuration, that might be nice. The installer could then ask for the location of CATALINA_BASE and offer to create it if necessary. That way, users performing upgrades could specify their existing CATALINA_BASE during installation and not have to go back and re-configure the Windows Service. It would also allow newbies to know that there is an advanced configuration and perhaps go learn about it. - -chris The Tomcat zip file distribution could easily do this now. Add a CATALINA_BASE directory pre-configured with a read-me file that explains to users they can move this directory elsewhere, and update a property that points back to the CATALINA_HOME directory wherever they unzipped that. This would be an easy optional configuration to include for a split configuration.
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, On 11/3/2014 3:08 PM, Christopher Schultz wrote: Mark, On 11/3/14 5:46 PM, Mark Eggers wrote: One of the issues I did run into when using tcnative-1.dll is that I got the following error message: 12.0.0.1 is not a recognized command, and Tomcat failed to start. Moving tcnative-1.dll out of the bin directory fixed the problem. When I specified JRE_HOME in setenv.bat, that also fixed the problem and allowed me to use tcnative-1.dll. I suspect some brokenness in the way NetBeans is handling the JRE_HOME environment variable, since I do have that set system-wide. That's weird. It looks like someone a) mistyped 127.0.0.1 for localhost and b) a script isn't working properly. That should have been 127.0.0.1 Is this Netbeans-only, or does it happen with a stock Tomcat? It is NetBeans-only. Stock 8.0.14 starts fine using startup.bat from Windows Explorer. It's also odd that it has something to do with using tcnative at the same time. That was my quick and dirty thought since I did a grep (cygwin) on all of the files in CATALINA_HOME/bin, and that's the only file that mentioned 127.0.0.1. I moved tcnative-1.dll out of the bin directory and Tomcat started from within NetBeans. I then added a setenv.bat file to the directory which explicitly sets JRE_HOME (even though it's set as a global environment variable). NetBeans was then able to launch Tomcat even with tcnative-1.dll in the bin directory. I'll poke around if I have some time. I'll also see if this occurs on a Linux platform. -chris . . . . just my two cents /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJUWPqxAAoJEEFGbsYNeTwtPooH/jpXYxwe5h97IsuI3kZ8Uprw OC2pTuJI8R95q1nATELEH44uMdWyu9YV6zyT0idkbZmdjU/VeFw7+QrtTop7or4J 4SH3ZTAFcvW4VqaQP3Z24kG1+8T9vpug1RsWnWabh8ioHz6qYKPEgvKhxa+fOopL gCbzEVObywOS/bRexilbZeJYUmQQOncEeVuqAQMpVqCW2yOf4DLJ+jtb7NVAalj+ H+YhVW8Adtip4DR8Kd/C0hIl5R/Gf8uEQjqlVh0SEPS8GwZFo9QJFhS6XD5Q44XK 0cMx/OHD8I6T/OVBAqND+Wf1KXUTfBnjQF9XeJvgs6MVCgMN2LKeutWxKXs5OpY= =Qhdj -END PGP SIGNATURE- --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 11/4/14 10:46 AM, Leo Donahue wrote: On Tue, Nov 4, 2014 at 9:37 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Neven, On 11/3/14 6:42 PM, Neven Cvetkovic wrote: Vince, the current configuration works great: SLIGHTLY-OFFTOPIC: Although, I would love to see out-of-box setup for additional shared-lib folder, something other than TOMCAT/lib with Tomcat default libraries. Essentially, I would love to separate my customer shared libraries from Tomcat default libraries. I guess - question would be where are CATALINA_HOME/lib JAR files being loaded from? Can we add another directory to scan for libraries to be loaded? Is that configurable? I'm not sure about that, but if the Windows installer could ask the user if they want a unified versus split configuration, that might be nice. The installer could then ask for the location of CATALINA_BASE and offer to create it if necessary. That way, users performing upgrades could specify their existing CATALINA_BASE during installation and not have to go back and re-configure the Windows Service. It would also allow newbies to know that there is an advanced configuration and perhaps go learn about it. - -chris The Tomcat zip file distribution could easily do this now. Add a CATALINA_BASE directory pre-configured with a read-me file that explains to users they can move this directory elsewhere, and update a property that points back to the CATALINA_HOME directory wherever they unzipped that. This would be an easy optional configuration to include for a split configuration. It already does that, now: The CATALINA_BASE directory is preconfigured to be set to CATALINA_HOME, which is auto-detected by catalina.sh (.bat). CATALINA_BASE contains a readme file (RUNNING.txt) that explains how to change that default. I say that with all due snark, but it's really true: what you are talking about basically exists exactly as you describe. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUWQB0AAoJEBzwKT+lPKRYm5oP/i1vfUFBWIsUmdOxFWIt44fZ ZL2Rco0+WFoUblC5JVjG+vfkv/ZFwUtJnbWVokm5ZZVtnD9LSwHvimeKMaq/wNSr 5yh+M/7cQXGmLEJV6tFf7eLLgHtEmH4WRgoWs/IJ827crxAjr2ae6w5HegWt8Yo1 r99g0x5ZFhlHBy8F1/xjykcTKZVYN3y7i47bcjgb0PDEC7rHB9RhLgveqwKPUU+x wDqKCHj6vLomgLL3adbU/kg5CV6UIgRwuD2Y3xuxHG3a4x3MoPfRhgmAzeetvm4i 9JXZGRbJhqs2mVNTBS3Bzwdj2rAF6LIROGwV/V7wqYDqgEIijssHUnY4GLaYbYOa kw+rpj7ZHfXfvmEFD5bo+7jc7v4Jp4SNQnES1bQJmhCytX/o/a0LjRuJ8H5WkTvA 2SobU1v9TMEtyu1esGjkcsibrCMqxfEmR3K8feKaRks1lCo2nlDKC5LsGrNykfW2 rI74FJyGCFP6sXOqckD6SGlyFXBrY4v6CI4sQc8iAsjPf8uWCyshfu7pWATC5C5g gr3ibDAQEICZWWlz3dlQuQtuf4sSU+XoLTWwyMls3fPMy/9+4BcvSPdcCmSKbGG2 +F9imb8uhrUOpLEhGo5pFBPx3JpjP0eBm1lU3WM3cWwFFBjBqt4GVBO9wFN9fjDg G+QWyQxZO/HdUUywyU6Z =zAEu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
SSL acceleration
Hello All, I am using a third party load balancer which accepts HTTPS connections, decrypts them and sends the unencrypted connection to Tomcat(SSL Acceleration). I am currently using tomcat 5 and I am in the process of upgrading to Tomcat 7. I am having an issue setting up Tomcat7 to accept the connections from my load balancer. In tomcat 5 I have the 2 connectors set up as so with everything working: Connector port=8080 maxHttpHeaderSize=8192 maxPostSize=512000 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true / Connector port=8081 maxHttpHeaderSize=8192 maxPostSize=512000 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8444 acceptCount=100 connectionTimeout=2 scheme=https proxyPort=443 disableUploadTimeout=true / The load balancer sends unencrypted HTTPS traffic to Tomcat via port 8081. This is setup is n place now with the current setup so the client does not have HTTPS changed to HTTP during a session, do to tomcat thinking the HTTPS connection is unencrypted and it should be changed to HTTP. There is no keystore or certs used by tomcat, all certs are placed on the load balancer. During setup of Tomcat 7 I copied the previous connector setup, resolving the following URLS I get the following responses respectively(I get the same results with my currenttly working Tomcat5 setup): https://localhost:8081/ - Secure connection fails http://localhost:8081/ - Apache Tomcat 7.0.56 page showing that everything works. My settings for tomcat 7 are: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8081 protocol=HTTP/1.1 maxThreads=150 SSLEnabled=false scheme=https secure=true clientAuth=false sslProtocol=TLS proxyPort=443/ I was wondering if there is a way to setup Tomcat 7 to accept the unencrypted request(SSL Acceleration) from the load balancer, process the request and send back a response without changing the scheme to HTTP? Also as expected my load balancer is not able to establish a connection with Tomcat7 over HTTPS port 8081. Any advice would be greatly appreciated. Thank you, Anthony Bonafide
Re: SSL acceleration
On Tue, Nov 4, 2014 at 11:47 AM, Anthony Bonafide bonafideanth...@gmail.com wrote: Hello All, I am using a third party load balancer which accepts HTTPS connections, decrypts them and sends the unencrypted connection to Tomcat(SSL Acceleration). I am currently using tomcat 5 and I am in the process of upgrading to Tomcat 7. I am having an issue setting up Tomcat7 to accept the connections from my load balancer. In tomcat 5 I have the 2 connectors set up as so with everything working: Connector port=8080 maxHttpHeaderSize=8192 maxPostSize=512000 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true / Connector port=8081 maxHttpHeaderSize=8192 maxPostSize=512000 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8444 acceptCount=100 connectionTimeout=2 scheme=https proxyPort=443 disableUploadTimeout=true / The load balancer sends unencrypted HTTPS traffic to Tomcat via port 8081. This is setup is n place now with the current setup so the client does not have HTTPS changed to HTTP during a session, do to tomcat thinking the HTTPS connection is unencrypted and it should be changed to HTTP. There is no keystore or certs used by tomcat, all certs are placed on the load balancer. During setup of Tomcat 7 I copied the previous connector setup, resolving the following URLS I get the following responses respectively(I get the same results with my currenttly working Tomcat5 setup): https://localhost:8081/ - Secure connection fails http://localhost:8081/ - Apache Tomcat 7.0.56 page showing that everything works. My settings for tomcat 7 are: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8081 protocol=HTTP/1.1 maxThreads=150 SSLEnabled=false scheme=https secure=true clientAuth=false sslProtocol=TLS proxyPort=443/ I was wondering if there is a way to setup Tomcat 7 to accept the unencrypted request(SSL Acceleration) from the load balancer, process the request and send back a response without changing the scheme to HTTP? Also as expected my load balancer is not able to establish a connection with Tomcat7 over HTTPS port 8081. Any advice would be greatly appreciated. If your load balancer is terminating SSL and properly setting X-Forwarded-* headers you can probably get away with one connector for HTTP traffic and the RemoveIpValve. The valve will use the X-Forwarded-* headers to modify the request object so that your apps can see if the request came in over SSL. http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_IP_Valve Dan
Re: Separation of CATALINA_HOME and CATALINA_BASE
On Tue, Nov 4, 2014 at 10:36 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leo, On 11/4/14 10:46 AM, Leo Donahue wrote: On Tue, Nov 4, 2014 at 9:37 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Neven, On 11/3/14 6:42 PM, Neven Cvetkovic wrote: Vince, the current configuration works great: SLIGHTLY-OFFTOPIC: Although, I would love to see out-of-box setup for additional shared-lib folder, something other than TOMCAT/lib with Tomcat default libraries. Essentially, I would love to separate my customer shared libraries from Tomcat default libraries. I guess - question would be where are CATALINA_HOME/lib JAR files being loaded from? Can we add another directory to scan for libraries to be loaded? Is that configurable? I'm not sure about that, but if the Windows installer could ask the user if they want a unified versus split configuration, that might be nice. The installer could then ask for the location of CATALINA_BASE and offer to create it if necessary. That way, users performing upgrades could specify their existing CATALINA_BASE during installation and not have to go back and re-configure the Windows Service. It would also allow newbies to know that there is an advanced configuration and perhaps go learn about it. - -chris The Tomcat zip file distribution could easily do this now. Add a CATALINA_BASE directory pre-configured with a read-me file that explains to users they can move this directory elsewhere, and update a property that points back to the CATALINA_HOME directory wherever they unzipped that. This would be an easy optional configuration to include for a split configuration. It already does that, now: The CATALINA_BASE directory is preconfigured to be set to CATALINA_HOME, which is auto-detected by catalina.sh (.bat). CATALINA_BASE contains a readme file (RUNNING.txt) that explains how to change that default. I say that with all due snark, but it's really true: what you are talking about basically exists exactly as you describe. - -chris You are correct (something muffled). If the Tomcat community wants to promote the concept of running multiple instances, then what about: A. A description of that functionality kind of starts on line 68 in RUNNING.txt ((3) Configure Environment Variables). In other words, it's buried. B. That description is aimed at using SCRIPTS not SERVICES to get it working. C. Under Advanced Configuration in RUNNING.txt all newbies really need to know is the In CATALINA_BASE part, because they will read the In CATALINA_HOME part and get confused. D. Are newbies after this kind of configuration for the thrill of being able to run multiple instances or for easier upgrades? My guess is most Tomcat users on Windows don't start their Tomcats with the scripts, a few do and those few are the ones who benefit from this ability, in their web app development. I haven't seen or heard of anyone who has a shared CATALINA_HOME sitting on a Windows file share where developers are free to create their own CATALINA_BASE, but I have only worked a few places in my life. And, I would wonder how coordinating the conflicting ports would be resolved as a group. leo
Re: Separation of CATALINA_HOME and CATALINA_BASE
Thanks Chris!
On Tue, Nov 4, 2014 at 10:41 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
I guess, it's easy to add new directories to
TOMCAT/conf/catalina.properties file:
common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
to now read:
common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,${catalina.base}/shared,${catalina.base}/shared/*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar
just use shared.loader, which is I think what you're asking for.
It's blank in a default configuration.
Yes, I missed that one :) that's what I had in mind.
What are you thoughts? Would it make sense to keep a separate
directory for shared libraries? Should we make it default - to
encourage others to create a directory if they want to.
- -1
This is confusing and would be surprising if you hadn't intended to
use this. The shared loader was disabled by default because nobody
could figure out what the heck it was for and basically continually
broke their own configurations using it. So, now, everything goes into
either lib/ or the web application's WEB-INF/lib and everyone seems to
be happy. One can always re-enable the shared loader if you know it
exists, in which case you probably know what it's for and why you'd
use it. (Hint: use of the shared loader almost never makes any sense).
Agreed, it might confusing. It's probably better idea to pack up your
libraries with your apps in WEB-INF/lib.
Why do shared loaders almost never make any sense? What kind of problems
did you have with shared.loader?
However, here's an (rare) example where that might be useful:
- one box with limited memory
- one tomcat instance hosting X (e.g. 10) applications
- all applications are using the same large shared libraries - e.g. 200MB
- you don't want to have a separate libraries for each application (your
PermGen space will grow significantly otherwise)
- it might make sense to move the shared libraries into shared folder (or
tomcat/lib)
Now, this architecture is probably not the greatest idea. I always strive
for the application/process isolation, i.e.
one-application-per-tomcat-instance - so I can have independent lifecycles
for my apps, but that requires more resources (memory,cpu) or even more
hardware.
I like the current default configuration but I'm willing to entertain
other ideas. I just don't like this one in particular (default to
split configuration).
So, I do agree - keeping it how it is - is probably the best idea. There is
always an option for people that would like to configure that further.
Thanks!
Neven
PS. Apologies for the off-topic diversion :)
Re: Separation of CATALINA_HOME and CATALINA_BASE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Neven,
On 11/4/14 1:05 PM, Neven Cvetkovic wrote:
Thanks Chris!
On Tue, Nov 4, 2014 at 10:41 AM, Christopher Schultz
ch...@christopherschultz.net wrote:
I guess, it's easy to add new directories to
TOMCAT/conf/catalina.properties file:
common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
to now read:
common.loader=
${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar,${catalina.base}/shared,${catalina.base}/shared/*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar
just use shared.loader, which is I think what you're asking for.
It's blank in a default configuration.
Yes, I missed that one :) that's what I had in mind.
What are you thoughts? Would it make sense to keep a separate
directory for shared libraries? Should we make it default - to
encourage others to create a directory if they want to.
- -1
This is confusing and would be surprising if you hadn't intended
to
use this. The shared loader was disabled by default because
nobody could figure out what the heck it was for and basically
continually broke their own configurations using it. So, now,
everything goes into either lib/ or the web application's
WEB-INF/lib and everyone seems to be happy. One can always
re-enable the shared loader if you know it exists, in which case
you probably know what it's for and why you'd use it. (Hint: use
of the shared loader almost never makes any sense).
Agreed, it might confusing. It's probably better idea to pack up
your libraries with your apps in WEB-INF/lib.
Why do shared loaders almost never make any sense? What kind of
problems did you have with shared.loader?
The only use case I've seen in the past for using a shared loader is
when people get paranoid about disk space and want to put all their
libraries under shared so they don't have extra copies of e.g.
Struts, Spring, etc. when all of their web applications depend on the
same set of prerequisites.
Of course, then we get endless questions about why their app A doesn't
work anymore because they have Spring 3.5 installed in their shared
loaded and Spring 4.0 installed in their web application and
everything goes all to hell. Basically, they outsmarted themselves and
the code is punishing them for it.
Tomcat then gets blamed for an inflexible configuration system when
Tomcat's flexibility is what allowed them to set up this foolish
configuration in the first place.
I think most of us are better off without the shared loader.
However, here's an (rare) example where that might be useful: - one
box with limited memory - one tomcat instance hosting X (e.g. 10)
applications - all applications are using the same large shared
libraries - e.g. 200MB - you don't want to have a separate
libraries for each application (your PermGen space will grow
significantly otherwise) - it might make sense to move the shared
libraries into shared folder (or tomcat/lib)
Agreed, but with the caveats indicated above.
Now, this architecture is probably not the greatest idea. I always
strive for the application/process isolation, i.e.
one-application-per-tomcat-instance - so I can have independent
lifecycles for my apps, but that requires more resources
(memory,cpu) or even more hardware.
Exactly: packaging your application as a self-contained unit means
fewer surprises all around.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUWRumAAoJEBzwKT+lPKRY/GYP+wc5EaHui1jmx1JoAtps9Z8W
F51OL86n43SpQYN6kpkr2nsew8vpApPX6MXrC8C2XY7AIGzXdclxTmt6Wcf+Rllj
bVrGFDe+tO7NKS44M4z4ZRRAlg7xVc0i/E9rHMdkxSPatDbsBM6t08R8x5se/l8/
C/iscgqVGXTmvA52c2xBLJmXiwXCDSb24HDji2kUzNo7irlaX4QxpvAWNUoCF566
4/tv4xvOrfDbo4INfQ+QtJbEMdFJNlJ2GtPYBF9jmsO9DGMUJ5PIkd7E7vbDr0Ac
fuKGFEiYpOIKNd9PZ99z/bV+Wo8DIpw5kzAUQArQzXqxq0BvNcErVnY5JM4mAyaE
rt4m8TRPCxgwQIuNk9dO7jG25PhDbzw/RWnoiGbbWrV+uBLwpUMU3htMgXuhuAO1
lHa8GaiRFRFBCBeI1yG8PzZEks9DoB5MCXS1tzBIN855bSL4rgYwAMSeTKTfaxzK
DCUJHcKQ71Bcq1neMVsVv3SAPCo4gsi4JPquhiJLo3WIqSV/MVX9rshRQ83VnrAO
nxobgJFsnXXe8VouPLlR6NyR8w9H6EwoTUM6ARayAUtfSqBaKBym/6Cylc71QnrG
HCCxuey8GP7dt8nnSqTkfthmojgfPZl6cAQ1RV2FRcnHcLMtJgPjGfTxuiXBtg1m
FCGaUtFhBsdmsQpdYLN4
=dNsl
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL acceleration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 11/4/14 12:02 PM, Daniel Mikusa wrote: On Tue, Nov 4, 2014 at 11:47 AM, Anthony Bonafide bonafideanth...@gmail.com wrote: Hello All, I am using a third party load balancer which accepts HTTPS connections, decrypts them and sends the unencrypted connection to Tomcat(SSL Acceleration). I am currently using tomcat 5 and I am in the process of upgrading to Tomcat 7. I am having an issue setting up Tomcat7 to accept the connections from my load balancer. In tomcat 5 I have the 2 connectors set up as so with everything working: Connector port=8080 maxHttpHeaderSize=8192 maxPostSize=512000 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true / Connector port=8081 maxHttpHeaderSize=8192 maxPostSize=512000 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8444 acceptCount=100 connectionTimeout=2 scheme=https proxyPort=443 disableUploadTimeout=true / The load balancer sends unencrypted HTTPS traffic to Tomcat via port 8081. This is setup is n place now with the current setup so the client does not have HTTPS changed to HTTP during a session, do to tomcat thinking the HTTPS connection is unencrypted and it should be changed to HTTP. There is no keystore or certs used by tomcat, all certs are placed on the load balancer. During setup of Tomcat 7 I copied the previous connector setup, resolving the following URLS I get the following responses respectively(I get the same results with my currenttly working Tomcat5 setup): https://localhost:8081/ - Secure connection fails http://localhost:8081/ - Apache Tomcat 7.0.56 page showing that everything works. My settings for tomcat 7 are: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8081 protocol=HTTP/1.1 maxThreads=150 SSLEnabled=false scheme=https secure=true clientAuth=false sslProtocol=TLS proxyPort=443/ I was wondering if there is a way to setup Tomcat 7 to accept the unencrypted request(SSL Acceleration) from the load balancer, process the request and send back a response without changing the scheme to HTTP? Also as expected my load balancer is not able to establish a connection with Tomcat7 over HTTPS port 8081. Any advice would be greatly appreciated. If your load balancer is terminating SSL and properly setting X-Forwarded-* headers you can probably get away with one connector for HTTP traffic and the RemoveIpValve. The valve will use the X-Forwarded-* headers to modify the request object so that your apps can see if the request came in over SSL. http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_IP_Valve +1 Another thing you need to do is to set scheme=https /and/ secure=true on the Connector, otherwise Tomcat will try to redirect until it gets a connection on a secure connector. FYI the redirectPort configuration looks a little insane to me. I think you want redirectPort=443 in all cases. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUWRxsAAoJEBzwKT+lPKRYdXoP/0+J0IVuYnMibaMqxczQ0Pjz dZNYJU+p0a/T//huAMwBhCGk7JMlW0bOcVxQA1RxxZ1E6vbNscikO1A1p0IuOaSe YSyVUHTxGnW+DQO7Gd+85UIm3QHlbK21UlLH3NIPoGYQVS6ldZkGqChLMAgO4hfV IOlb2dl/+Vd3OzG5EsFHn9LASnJH4N1QsWqWAM4KnLopeMhmS+pVcQJ8WOcE5cHR TDLlc3XcaWcdhSch8cynv2498TfmqO+4yEhVHKHscY2tn6BHiuHcQW+hljIlxcF0 Ru9sV6CWftA6iaLKAIp+A4kHRVDoqhkVRokUpDEcv14T9V0QhoVBByqz/ez98UQZ SWh6DaUqr7wz3Gg2+uLbjDtfcLyVdcKahbC6tHeatuS/0lHXfAjRhpeeNeurFlYV VaYfKuapf15TywoRU+DM/GgWzJHz5NdqgimtwTuqNI3zLsSIjOzuCB16Sh3Z6M60 KHqGvuSXKn2zy3YxJY2GVLPcu9Iq6omPRTMHU864SbJiUYjlGv4OwBymjWoRDFZX Z8c3r7cqt3/1fpMJygdsYQZhSDFQGm+zp0tTpNBD+/xKPIJNezpWl0AJRuNyciZr EXlRttpO+bN5PaXCkxKGg3VO0GIPk/Yhm8DhWFZmrvUsjIwbLHKWythxcVcBEjnz dZKnPvqnGGpz/TEgibve =uX/w -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
PID file locked on Windows 2008 system
Hi, We have a requirement to read the PID file created by the Tomcat server process on Windows, but we are not able to using RandomAccessFile or FileInputStream because the file seems to be locked by the Tomcat process. Why does the Tomcat server keep the PID file locked, preventing other processes to even read the file? Is there a work around or solution for this problem? Any help is appreciated. Thank you in advance. Regards, Regards, Anilkumar Ambati 4205 S Miami Blvd WebSphere Virtual Enterprise Development Durham, 27703-9141 Phone: +1-919-254-6152 USA Mobile: +1-919-434-5674 e-mail: aamb...@us.ibm.com You have no responsibility to live up to what other people think you ought to accomplish. -Richard Feynman (1918-1988)
Re: PID file locked on Windows 2008 system
On 11/4/2014 2:58 PM, Anil Ambati wrote: Hi, We have a requirement to read the PID file created by the Tomcat server process on Windows, but we are not able to using RandomAccessFile or FileInputStream because the file seems to be locked by the Tomcat process. What is the PID file? The only abbreviation I know by that name is the Process ID, which is just a number. Why does the Tomcat server keep the PID file locked, preventing other processes to even read the file? Is there a work around or solution for this problem? Any help is appreciated. Thank you in advance. Regards, Regards, *Anilkumar Ambati* 4205 S Miami Blvd WebSphere Virtual Enterprise Development Durham, 27703-9141 Phone: +1-919-254-6152 USA Mobile: +1-919-434-5674 e-mail: aamb...@us.ibm.com You have no responsibility to live up to what other people think you ought to accomplish. -Richard Feynman (1918-1988) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PID file locked on Windows 2008 system
I was referring to the .pid file Tomcat server creates in the logs directory. This file contains the process ID of the Tomcat process. Regards, Anilkumar Ambati 4205 S Miami Blvd WebSphere Virtual Enterprise Development Durham, 27703-9141 Phone: +1-919-254-6152 USA Mobile: +1-919-434-5674 e-mail: aamb...@us.ibm.com You have no responsibility to live up to what other people think you ought to accomplish. -Richard Feynman (1918-1988) From: David kerber dcker...@verizon.net To: Tomcat Users List users@tomcat.apache.org, Date: 11/04/2014 03:45 PM Subject: Re: PID file locked on Windows 2008 system On 11/4/2014 2:58 PM, Anil Ambati wrote: Hi, We have a requirement to read the PID file created by the Tomcat server process on Windows, but we are not able to using RandomAccessFile or FileInputStream because the file seems to be locked by the Tomcat process. What is the PID file? The only abbreviation I know by that name is the Process ID, which is just a number. Why does the Tomcat server keep the PID file locked, preventing other processes to even read the file? Is there a work around or solution for this problem? Any help is appreciated. Thank you in advance. Regards, Regards, *Anilkumar Ambati* 4205 S Miami Blvd WebSphere Virtual Enterprise DevelopmentDurham, 27703-9141 Phone: +1-919-254-6152 USA Mobile:+1-919-434-5674 e-mail:aamb...@us.ibm.com You have no responsibility to live up to what other people think you ought to accomplish. -Richard Feynman (1918-1988) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PID file locked on Windows 2008 system
On 11/4/2014 4:21 PM, Anil Ambati wrote: I was referring to the .pid file Tomcat server creates in the logs directory. This file contains the process ID of the Tomcat process. What version of Tomcat, Windows, and Java are you using? My 7.0.54 doesn't seem to create that file anywhere in the file system. Regards, *Anilkumar Ambati* 4205 S Miami Blvd WebSphere Virtual Enterprise Development Durham, 27703-9141 Phone: +1-919-254-6152 USA Mobile: +1-919-434-5674 e-mail: aamb...@us.ibm.com You have no responsibility to live up to what other people think you ought to accomplish. -Richard Feynman (1918-1988) From: David kerber dcker...@verizon.net To: Tomcat Users List users@tomcat.apache.org, Date: 11/04/2014 03:45 PM Subject:Re: PID file locked on Windows 2008 system On 11/4/2014 2:58 PM, Anil Ambati wrote: Hi, We have a requirement to read the PID file created by the Tomcat server process on Windows, but we are not able to using RandomAccessFile or FileInputStream because the file seems to be locked by the Tomcat process. What is the PID file? The only abbreviation I know by that name is the Process ID, which is just a number. Why does the Tomcat server keep the PID file locked, preventing other processes to even read the file? Is there a work around or solution for this problem? Any help is appreciated. Thank you in advance. Regards, Regards, *Anilkumar Ambati* 4205 S Miami Blvd WebSphere Virtual Enterprise Development Durham, 27703-9141 Phone: +1-919-254-6152 USA Mobile: +1-919-434-5674 e-mail: aamb...@us.ibm.com You have no responsibility to live up to what other people think you ought to accomplish. -Richard Feynman (1918-1988) - 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: PID file locked on Windows 2008 system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Anil, On 11/4/14 2:58 PM, Anil Ambati wrote: We have a requirement to read the PID file created by the Tomcat server process on Windows, but we are not able to using RandomAccessFile or FileInputStream because the file seems to be locked by the Tomcat process. Why does the Tomcat server keep the PID file locked, preventing other processes to even read the file? Is there a work around or solution for this problem? You must be using commons-daemon's procrun, otherwise known as the Windows service wrapper. That process creates (and possibly locks) the PID file for Tomcat. You may find users here who know the answer to your question, but you might have better luck posting to the commons mailing list to ask there. I suspect it's something silly like holding-open the PID file instead of writing to it and then closing it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUWVJWAAoJEBzwKT+lPKRYo0UP/A/HW0TvHf24Esw4tK+wlbLG tOwruOGaSC+fwO+hSnSszwmrbRbgwcD6EKwPuueO7aUy3Gp5rCIjnqH13J34It8m /31oO8ILwawUpDpup+QZnPOdgxPUfvVBf0Sobiec5HNTNcfiCvqjF4qBB0Eedbt/ SMmaRBzNSOzSog4LpBKskHaBJSlt65UqMUS0sk2DrbYO+aJRCYA6hv8f5w8gWB0d c6z6KOHncVweFiN3fl8PXabKcTWvSEiLh4c+TdXLfC6syMIAQxjo+w5GSOgzQsEU ujWh/aB1FSKltNzvW0/2AKABKBH4r6ODuG7bpjrrQ3xSWZch2j8pFGqYgyuCVBwB EHclh9d18RYba031r01I9o9tDHGlt1DewquccBgb5m0qRduESqtI0/LYRpr0QUTP 6kgR2CCwi81d2OR8ifk6Jhs58ChGzWq4lpeR8ZAd+xsN/1VozznU0XvOOzNd8E6s qjZMYbSjaoFFPNHJNXW1ZrfIXfTrFWXHwO4e29BxZrKFhB4I3pL84GrQqO7jOFpc 5jO+avhdOGnAb7I/A2mz3b+XKqVL1Ob+U7rfL3uaUeZbuxraNZEqZuvyhgxZ9c23 Zwwyw5RoU0QOCpJJfhoTdsAlgPVSNAgcvhxPMChzQQepSIoGHAOg6cQi5pptNKgP 1TUe3h54UjuGqY1lJ0wO =sBXy -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PID file locked on Windows 2008 system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Anil, On 11/4/14 5:25 PM, Christopher Schultz wrote: Anil, On 11/4/14 2:58 PM, Anil Ambati wrote: We have a requirement to read the PID file created by the Tomcat server process on Windows, but we are not able to using RandomAccessFile or FileInputStream because the file seems to be locked by the Tomcat process. Why does the Tomcat server keep the PID file locked, preventing other processes to even read the file? Is there a work around or solution for this problem? You must be using commons-daemon's procrun, otherwise known as the Windows service wrapper. That process creates (and possibly locks) the PID file for Tomcat. You may find users here who know the answer to your question, but you might have better luck posting to the commons mailing list to ask there. I suspect it's something silly like holding-open the PID file instead of writing to it and then closing it. I took a quick look, and it looks like the PID file is being created with a file option FILE_FLAG_DELETE_ON_CLOSE which causes the OS to delete the file off the disk when all file handles are closed. So, closing the file handle will result in the PID file being deleted. This option was added because the PID file wasn't being removed if the service crashed, which kept the service from restarting (oops). https://issues.apache.org/jira/browse/DAEMON-183 It seems like an option to control what happens on startup when the PID file already exists would be a good idea. You'll have to ask the procrun folks about what the options are. It seems reasonable to be able to read the PID file, since not being able to read it makes it kind of useless other than as a lock-file (i.e. its contents are irrelevant). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUWVVlAAoJEBzwKT+lPKRYrQsP+wVCM1ASSBh+LuNIPjRUkUxi 3uBfjLArQIplC0l98dIQZZlBJQAsh0Lc61Tvo2Q+Ka5zPtq+WA9GlDVTH3MZo82E kcleNxwFcmx0fGWizStEhMsxGqtGAKWct68FwVTFKDb8Bl68ud20fqJ5bEyyL6lP 2kV8QTjRcqJs42NvpjmW14NBGzXWiGF5BKOh3dGTdp1h6kIZrcOY/oOfX8noaO/K evMDRrCas/MARzUQ/gBGMoZN5KmqPFcAvotlJlhECg1bpMTX38etIAwnMsnFRuZ9 Y0Ci5ffQ5I3MDvyWUf5Sv8UBJHLGUjwXzKbWCagDfBtgOZxp389t8Ro1TWDtMF7l KWO9wvjX0Y1oS13xrl4VNNr/6oQuvybSwKYtMrFycRB8/K573QHrgSixI+7lNWNk jyNus6cpOINxhMxsuyyu5oF+1O7EV0yWhXT+EIWt7mpzXLsyjQc/XbpFwQ3anNUv YrD+CB+I/FLA/O1RSEEd9+NzpO45laSyoz3KfIqVFMkqCLKyjdA652jR+ik978kX fc5gsQVtoeGAuTbNTm9eSS9hv2wjJoMSl0A6gT9Y8q83448IlhaSYE1mXSYG6XIp DxNe0Dci0M5biNju+OIWrtW23zG4Q1eW8MIvs5wltVl8873zLdPpc49+dg3H+xIs Mj55IlSYkg4GMHtdohle =fhDz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PID file locked on Windows 2008 system
On 11/4/2014 5:25 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Anil, On 11/4/14 2:58 PM, Anil Ambati wrote: We have a requirement to read the PID file created by the Tomcat server process on Windows, but we are not able to using RandomAccessFile or FileInputStream because the file seems to be locked by the Tomcat process. Why does the Tomcat server keep the PID file locked, preventing other processes to even read the file? Is there a work around or solution for this problem? You must be using commons-daemon's procrun, otherwise known as the Windows service wrapper. That process creates (and possibly locks) the PID file for Tomcat. This is only peripherally related to the OP, but is there a situation where that file is not created, when using the windows service wrapper? I run a dozen or so instances of TC 7.0.54 as separate services on Windows 2008 R2 using the included renamed version of procrun, and don't have any pid files anywhere that I can find on my file system. You may find users here who know the answer to your question, but you might have better luck posting to the commons mailing list to ask there. I suspect it's something silly like holding-open the PID file instead of writing to it and then closing it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUWVJWAAoJEBzwKT+lPKRYo0UP/A/HW0TvHf24Esw4tK+wlbLG tOwruOGaSC+fwO+hSnSszwmrbRbgwcD6EKwPuueO7aUy3Gp5rCIjnqH13J34It8m /31oO8ILwawUpDpup+QZnPOdgxPUfvVBf0Sobiec5HNTNcfiCvqjF4qBB0Eedbt/ SMmaRBzNSOzSog4LpBKskHaBJSlt65UqMUS0sk2DrbYO+aJRCYA6hv8f5w8gWB0d c6z6KOHncVweFiN3fl8PXabKcTWvSEiLh4c+TdXLfC6syMIAQxjo+w5GSOgzQsEU ujWh/aB1FSKltNzvW0/2AKABKBH4r6ODuG7bpjrrQ3xSWZch2j8pFGqYgyuCVBwB EHclh9d18RYba031r01I9o9tDHGlt1DewquccBgb5m0qRduESqtI0/LYRpr0QUTP 6kgR2CCwi81d2OR8ifk6Jhs58ChGzWq4lpeR8ZAd+xsN/1VozznU0XvOOzNd8E6s qjZMYbSjaoFFPNHJNXW1ZrfIXfTrFWXHwO4e29BxZrKFhB4I3pL84GrQqO7jOFpc 5jO+avhdOGnAb7I/A2mz3b+XKqVL1Ob+U7rfL3uaUeZbuxraNZEqZuvyhgxZ9c23 Zwwyw5RoU0QOCpJJfhoTdsAlgPVSNAgcvhxPMChzQQepSIoGHAOg6cQi5pptNKgP 1TUe3h54UjuGqY1lJ0wO =sBXy -END PGP SIGNATURE- - 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
Trying to filter noise from catalina.out.
Looking for configuration help. Using tomcat7 7.0.34 from rpm package tomcat7-7.0.34-3.jpp6.noarch. Followed the instructions for using log4j for catalina.out found here: http://tomcat.apache.org/tomcat-7.0-doc/logging.html#Using_Log4j Took the example log4j.properties file from the instructions above, corrected the logging paths for /var/log/tomcat7, and put it through a properties to xml converter. Replaced log4j.properties with log4j.xml, and logging is working. Now we want to try and filter out an Exception we are willing to live with, but can't have overflowing our log. Added the following filter: filter class=org.apache.log4j.filter.ExpressionFilter param name=expression value=EXCEPTION ~= java.io.NotSerializableException / param name=acceptOnMatch value=false/ /filter Yet we continue to get the exception in the log: Nov 4, 2014 1:52:45 PM net.sf.ehcache.distribution.RMISynchronousCacheReplicator replicatePutNotification SEVERE: Exception on replication of putNotification. error marshalling arguments; nested exception is: java.io.NotSerializableException: com.fakename.services.cache.ehcache.EHCacheServiceImpl. Continuing... java.rmi.MarshalException: error marshalling arguments; nested exception is: java.io.NotSerializableException: com.fakename.services.cache.ehcache.EHCacheServiceImpl at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:138) ...snip... Caused by: java.io.NotSerializableException: com.fakename.services.cache.ehcache.EHCacheServiceImpl at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) ...snip... What am I doing wrong? Full xml and/or log of error available if requested. *Brandon Darbro - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PID file locked on Windows 2008 system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 11/4/14 5:54 PM, David kerber wrote: On 11/4/2014 5:25 PM, Christopher Schultz wrote: Anil, On 11/4/14 2:58 PM, Anil Ambati wrote: We have a requirement to read the PID file created by the Tomcat server process on Windows, but we are not able to using RandomAccessFile or FileInputStream because the file seems to be locked by the Tomcat process. Why does the Tomcat server keep the PID file locked, preventing other processes to even read the file? Is there a work around or solution for this problem? You must be using commons-daemon's procrun, otherwise known as the Windows service wrapper. That process creates (and possibly locks) the PID file for Tomcat. This is only peripherally related to the OP, but is there a situation where that file is not created, when using the windows service wrapper? I run a dozen or so instances of TC 7.0.54 as separate services on Windows 2008 R2 using the included renamed version of procrun, and don't have any pid files anywhere that I can find on my file system. Sure: if you don't specify a --PidFile argument in procrun, you won't get a PID file. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUWV8WAAoJEBzwKT+lPKRYXj0P/jTfRf4NQ2ozxcgIz1kW5SHL QiSy4lEZnMoN7U52rLDIOH40z4eSp3Q5RqZh5eFbsWGuQBHm0n9DEa1KcR0oXKMD SYzUnYdelfwi/TeG9dPSzHowMjLPhKE4h5p/fKwNx1tfsuFTbZ2rfLAlEl9XH8Zz nJ79cN+gxF2n3Dy9+JA86nwO/bACQyMToK1rVjtofSpNGD5Q87ehMDY3BviEh0TX 6Y+TeEzRsgSCyrrNBLw5brfJloqAqf94NEDklytDuWSbCbVA5Sru7/KRVHE/RUmr TUppuaNgZ3zwS3X8k+24duTQbvRc0ADPu94MbBYjcrIyti1BUfhoZQ9yvVLIxZOo IT2WkhT34u8l1aDQcdkYc3DX4Osag03kHkEpoJiC8ALe79RSy6b+h/5xFbIZ1gZ5 UgXEsGCylAVErXlsz2695Ogt31LeCBOqoqmbfu1kpmAdZUDrlqG19lXy/hKgTlyB W5DlmvtgR1od95IiYM4qF02bXrE+PoscpWdsjvMXcJqEjm2g/y8tWD9vHYyjtakw 6kzwPZa/ew+EBmADh6G+SMkeS0826gnguHQXuuxq5GR24Ws7hT/QMhrK2AuPl5nd dnYfZ9taBvX+4giV6ZBny/nZGxux88/ZJ9S4yfRB4GvQh1cupfohra/xxkBX8+F8 vJUqSoRROGc5k9NJePWW =2WQg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PID file locked on Windows 2008 system
7.0.56 To make Tomcat to create a pid file , you need to specify name of the file in the Tomcat 7 properties window (To open this window select, Configure Tomcat menu option in the Windows Start menu) Regards, Anilkumar Ambati 4205 S Miami Blvd WebSphere Virtual Enterprise Development Durham, 27703-9141 Phone: +1-919-254-6152 USA Mobile: +1-919-434-5674 e-mail: aamb...@us.ibm.com You have no responsibility to live up to what other people think you ought to accomplish. -Richard Feynman (1918-1988) From: David kerber dcker...@verizon.net To: Tomcat Users List users@tomcat.apache.org, Date: 11/04/2014 04:37 PM Subject: Re: PID file locked on Windows 2008 system On 11/4/2014 4:21 PM, Anil Ambati wrote: I was referring to the .pid file Tomcat server creates in the logs directory. This file contains the process ID of the Tomcat process. What version of Tomcat, Windows, and Java are you using? My 7.0.54 doesn't seem to create that file anywhere in the file system. Regards, *Anilkumar Ambati* 4205 S Miami Blvd WebSphere Virtual Enterprise DevelopmentDurham, 27703-9141 Phone: +1-919-254-6152 USA Mobile:+1-919-434-5674 e-mail:aamb...@us.ibm.com You have no responsibility to live up to what other people think you ought to accomplish. -Richard Feynman (1918-1988) From: David kerber dcker...@verizon.net To:Tomcat Users List users@tomcat.apache.org, Date: 11/04/2014 03:45 PM Subject: Re: PID file locked on Windows 2008 system On 11/4/2014 2:58 PM, Anil Ambati wrote: Hi, We have a requirement to read the PID file created by the Tomcat server process on Windows, but we are not able to using RandomAccessFile or FileInputStream because the file seems to be locked by the Tomcat process. What is the PID file? The only abbreviation I know by that name is the Process ID, which is just a number. Why does the Tomcat server keep the PID file locked, preventing other processes to even read the file? Is there a work around or solution for this problem? Any help is appreciated. Thank you in advance. Regards, Regards, *Anilkumar Ambati* 4205 S Miami Blvd WebSphere Virtual Enterprise Development Durham, 27703-9141 Phone: +1-919-254-6152 USA Mobile: +1-919-434-5674 e-mail: aamb...@us.ibm.com You have no responsibility to live up to what other people think you ought to accomplish. -Richard Feynman (1918-1988) - 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: PID file locked on Windows 2008 system
Hi Chris, Thanks for the response. How can I ask procrun folks about the options? Is there another news group? Sorry , I am new to Tomcat. Regards, Anilkumar Ambati 4205 S Miami Blvd WebSphere Virtual Enterprise Development Durham, 27703-9141 Phone: +1-919-254-6152 USA Mobile: +1-919-434-5674 e-mail: aamb...@us.ibm.com You have no responsibility to live up to what other people think you ought to accomplish. -Richard Feynman (1918-1988) From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org, Date: 11/04/2014 05:39 PM Subject: Re: PID file locked on Windows 2008 system -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Anil, On 11/4/14 5:25 PM, Christopher Schultz wrote: Anil, On 11/4/14 2:58 PM, Anil Ambati wrote: We have a requirement to read the PID file created by the Tomcat server process on Windows, but we are not able to using RandomAccessFile or FileInputStream because the file seems to be locked by the Tomcat process. Why does the Tomcat server keep the PID file locked, preventing other processes to even read the file? Is there a work around or solution for this problem? You must be using commons-daemon's procrun, otherwise known as the Windows service wrapper. That process creates (and possibly locks) the PID file for Tomcat. You may find users here who know the answer to your question, but you might have better luck posting to the commons mailing list to ask there. I suspect it's something silly like holding-open the PID file instead of writing to it and then closing it. I took a quick look, and it looks like the PID file is being created with a file option FILE_FLAG_DELETE_ON_CLOSE which causes the OS to delete the file off the disk when all file handles are closed. So, closing the file handle will result in the PID file being deleted. This option was added because the PID file wasn't being removed if the service crashed, which kept the service from restarting (oops). https://issues.apache.org/jira/browse/DAEMON-183 It seems like an option to control what happens on startup when the PID file already exists would be a good idea. You'll have to ask the procrun folks about what the options are. It seems reasonable to be able to read the PID file, since not being able to read it makes it kind of useless other than as a lock-file (i.e. its contents are irrelevant). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUWVVlAAoJEBzwKT+lPKRYrQsP+wVCM1ASSBh+LuNIPjRUkUxi 3uBfjLArQIplC0l98dIQZZlBJQAsh0Lc61Tvo2Q+Ka5zPtq+WA9GlDVTH3MZo82E kcleNxwFcmx0fGWizStEhMsxGqtGAKWct68FwVTFKDb8Bl68ud20fqJ5bEyyL6lP 2kV8QTjRcqJs42NvpjmW14NBGzXWiGF5BKOh3dGTdp1h6kIZrcOY/oOfX8noaO/K evMDRrCas/MARzUQ/gBGMoZN5KmqPFcAvotlJlhECg1bpMTX38etIAwnMsnFRuZ9 Y0Ci5ffQ5I3MDvyWUf5Sv8UBJHLGUjwXzKbWCagDfBtgOZxp389t8Ro1TWDtMF7l KWO9wvjX0Y1oS13xrl4VNNr/6oQuvybSwKYtMrFycRB8/K573QHrgSixI+7lNWNk jyNus6cpOINxhMxsuyyu5oF+1O7EV0yWhXT+EIWt7mpzXLsyjQc/XbpFwQ3anNUv YrD+CB+I/FLA/O1RSEEd9+NzpO45laSyoz3KfIqVFMkqCLKyjdA652jR+ik978kX fc5gsQVtoeGAuTbNTm9eSS9hv2wjJoMSl0A6gT9Y8q83448IlhaSYE1mXSYG6XIp DxNe0Dci0M5biNju+OIWrtW23zG4Q1eW8MIvs5wltVl8873zLdPpc49+dg3H+xIs Mj55IlSYkg4GMHtdohle =fhDz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: From HTTP to HTTPS request.getHeader(referer)
On 11/4/2014 4:46 AM, Léa Massiot wrote: Hi, Terence M. Bandoian wrote: I'm not sure how you're using it but it's worth pointing out that response.sendRedirect Sends a temporary redirect response to the client... The client (browser) must then send another request to the server before any additional processing takes place. In contrast, pageContext.forward takes place entirely on the server. I didn't know that. I thought there was one HTTP(S) request and one HTTP(S) response only. How can the mechanism you describe above affect the use of HTTPS for a webapp with the CONFIDENTIAL security constraint on a standalone Tomcat server? I'm using sendRedirect() in a very straightforward way I think. I use some sort of pipelines for a subset S of JSPs in the webapp: 1) Given a JSP s in S, it contains a form with an action attribute mapped via web.xml to a servlet L. 2) The servlet L implements either a doPost() or (rarely) a doGet() method. 3) Given what was submitted via the form, work is performed in the servlet. 4) When the servlet work is done and depending on the result (success 1, ..., success n / error 1, ..., error n), the servlet redirects towards the next JSP using the method sendRedirect(). Is there a temporary redirect response to the client in that case? Is this behavior documented somewhere? I could totally benefit from a good documentation... Best regards. Hi, Léa- You can find information about HttpServletResponse and PageContext in the Java Servlet and JavaServer Pages specifications which are available on the Oracle web site. JavaDocs are also available online. Be sure to reference the appropriate versions of the specs and JavaDocs for your application. Links to copies of the JavaDocs are available on the Tomcat documentation pages: Tomcat 7 - https://tomcat.apache.org/tomcat-7.0-doc/index.html Tomcat 8 - https://tomcat.apache.org/tomcat-8.0-doc/index.html The links are labeled Servlet JavaDocs and JSP 2.x JavaDocs in the Reference section on the left. -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PID file locked on Windows 2008 system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Anil, On 11/4/14 6:27 PM, Anil Ambati wrote: Thanks for the response. How can I ask procrun folks about the options? Is there another news group? Sorry , I am new to Tomcat. Yes, you'll want to post to the commons users mailing list: http://commons.apache.org/proper/commons-daemon/mail-lists.html Please be aware that Apache commons is ... crowded. If you post to the list, please put [daemon] in the subject line to get some attention. Otherwise, you'll not cut through all the messages about mathematical solvers, parsers, file compression utilities and all the other things that have been dumped into commons over the years. We'd be interested in hearing the result of the discussion, so please post back here if/when you get an answer and/or resolution. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUWXchAAoJEBzwKT+lPKRYRbYP/0B/quqn9cvqG+cZWg0xjHHt Fq6/qseW+Br+rLRo1+oPSPe/PwDyGdHS39a7L4fFfXUeUeWUWYqv5VNmHN8qIjh2 C8B7KW/Kr2ZGhcI1gN8jhw9vzOlXwOqXH2VhwT6VHXPmFA8QGa8NteVdf29YLvzO H8V3f6mVIIOtTaNGXLGyQHTPw4IW0vpxZWeTt0b+jtJg3goKM8Tr7vs2dtqY8C5l UQUZ8o1u9wfAVsoTy/RSeDzRzdafsLYwjp9LNztxU/aDG/mghlbcjgKajnHgaQEn 6xvSRZ1anHZWHbbblpWHC7ak2MG2dvo8OMweblAxjbSEvppq9ngGt+0o3jBheVWJ 9soHHrJOJvz+FF/zYmoKTDRLd6/Y3iTkE/pYPOVZbHcWfGVEVHfCOh0dMeEwiuLw A8cnX2V4Tv0FeRst+UjuMAbCUrHrTH3dE63bJ3ioFJ1BXFXwxIkGjh2loRhDbU25 gqKGwYWOjzZU45X+GaSsmUap1khA1or2n+fwOzVU9UqoFlu6FpANHb81itK9FEhh jbOfxfffNspkCOpKK7MWn3Fe2ePTvHehUbbhgtCjScYBfhZviTsWmyg4PdpNt2wt jBEIRjc/EcaEgp3qW/aPUphN7WzYAR4UBbss2CpXn5YQa+WWok2j9KfuLaDw8xOf X798FCTr6j1ugiZaedlt =KW59 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
so many thread are blocked
I used command jstack to dump threads of tomcat, and I found that 183 threads are blocked, why? thread dump like this: Deadlock Detection: No deadlocks found. Thread 2584: (state = BLOCKED) - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise) - java.lang.Object.wait() @bci=2, line=485 (Compiled frame) - org.apache.tomcat.util.net.JIoEndpoint$Worker.await() @bci=8, line=458 (Compiled frame) - org.apache.tomcat.util.net.JIoEndpoint$Worker.run() @bci=11, line=484 (Interpreted frame) - java.lang.Thread.run() @bci=11, line=662 (Interpreted frame) Thread 2583: (state = BLOCKED) - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise) - java.lang.Object.wait() @bci=2, line=485 (Compiled frame) - org.apache.tomcat.util.net.JIoEndpoint$Worker.await() @bci=8, line=458 (Compiled frame) - org.apache.tomcat.util.net.JIoEndpoint$Worker.run() @bci=11, line=484 (Compiled frame) - java.lang.Thread.run() @bci=11, line=662 (Interpreted frame) Thread 2572: (state = BLOCKED) - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise) - java.lang.Object.wait() @bci=2, line=485 (Compiled frame) - org.apache.tomcat.util.net.JIoEndpoint$Worker.await() @bci=8, line=458 (Compiled frame) - org.apache.tomcat.util.net.JIoEndpoint$Worker.run() @bci=11, line=484 (Interpreted frame) - java.lang.Thread.run() @bci=11, line=662 (Interpreted frame) ... thanks.
RE: so many thread are blocked
From: bo zhao [mailto:somany...@gmail.com] Subject: so many thread are blocked I used command jstack to dump threads of tomcat, and I found that 183 threads are blocked, why? They're waiting for something to do. When a request arrives, a waiting thread will be activated to process it. Look at the Connector and Executor documentation to learn how to configure things to your liking. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat server starting problem -- GET /cgi-bin/im0dcsr9/b2b_index.jsp?dpAuthProxyStatus=Fail HTTP/1.1 500 539
When I try to start the tomcat by running the httpd. I get the below internal server error displayed on the console. In the access log the below highlighted is all I see. I do not understand yet, what the issue is. It was all working good. I am having a sofea (kind of angularJs based architecture) based application running on the tomcat. The issue started happening when I turned on my system from sleep/hibernation, basically I didn't shut down the tomcat properly before that, not sure if it was shut down even. But then I killed the tomcat and I restarted the tomcat didn't fix it. I even restarted my machine that too didn't fix it. I am still analyzing. Please share any inputs. Thanks. 127.0.0.1 - - [04/Nov/2014:22:38:01 -0500] GET /cgi-bin/im0dcsr9/b2b_index.jsp?dpAuthProxyStatus=Fail HTTP/1.1 500 539 Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, webmaster@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Thanks. From: Goli, Ravi (FKN) - contr Sent: Tuesday, November 04, 2014 11:25 PM To: 'users@tomcat.apache.org' Subject: Tomcat server starting problem -- GET /cgi-bin/im0dcsr9/b2b_index.jsp?dpAuthProxyStatus=Fail HTTP/1.1 500 539 When I try to start the tomcat by running the httpd. I get the below internal server error displayed on the console. In the access log the below highlighted is all I see. I do not understand yet, what the issue is. It was all working good. I am having a sofea (kind of angularJs based architecture) based application running on the tomcat. The issue started happening when I turned on my system from sleep/hibernation, basically I didn't shut down the tomcat properly before that, not sure if it was shut down even. But then I killed the tomcat and I restarted the tomcat didn't fix it. I even restarted my machine that too didn't fix it. I am still analyzing. Please share any inputs. Thanks. 127.0.0.1 - - [04/Nov/2014:22:38:01 -0500] GET /cgi-bin/im0dcsr9/b2b_index.jsp?dpAuthProxyStatus=Fail HTTP/1.1 500 539 Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, webmaster@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Thanks.
