Apache + mod_jk + Tomcat ... SSL Problems
Hello, we are using the following versions: Apache 2.0.47 mod_jk (not mod_jk2) Tomcat 5.5.9 The SSL-Feature is backed by openssl 0.9.7c. We configured mod_jk to send the SSL information to the tomcat engine: JkHTTPSIndicator HTTPS JkSESSIONIndicator SSL_SESSION_ID JkCIPHERIndicator SSL_CIPHER JkCERTSIndicator SSL_CLIENT_CERT And we configured the SSL-Module of Apache to use the SSL-Cache and to hold the SSL Session for 30 Minutes. SSLSessionCache dbm:logs/ssl_scache SSLSessionCacheTimeout 1800 Using the trick described in the tomcat documenation, I could activate and use the Session Tracking via the SSL Session ID, which is exactly what we wanted because so we don't need cookies or URL-Rewriting. To manage the SSL Sessions I implemented my own SSLSessionManager-Class in my Webapplication and all worked fine, except one little problem: The SSL Session Key seems to get lost by Apache or mod_ssl or OpenSSL! I used a test application in my servlet engine to experiment with the session tracking via ssl session id-feature. That application showed me if the SSL Session ID was set, what value it has, what my own SessionManagement-Class knew about that session (when it was created, when it was used last time, how long until expiration, which attributes are managed for that session). The SessionManager was configured to hold every SSL Session for unlimited time, only to set an internal invalid-flag after a configured time of 30 minutes. The test application showed that in newly started application instances (apache, tomcat) the SSL Session worked properly and the SSL Session ID was created. When reloading the test application repeatedly, that SSL Session ID kept its value. Bingo! All that I needed. But then... Few minutes later the test application showed that there was *no* SSL Session ID available within the https-request any longer. When I reloaded the test application again, a new SSL Session ID was created. This happened again and again later, always far earlier than the SSLSessionCache was configured. Then I used tomcat's web-connector and tried the same - and there the SSL Session ID worked properly and wasn't lost preemptively. Does someone know something about problems with SSL Session IDs with Apache und mod_jk? Does someone have a solution how to remove that problem? Thank you in advance, Oliver Schoenwald University of Hagen, Germany - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SSL Sessions in Tomcat 5.5.4
Hello, how do I track sessions without using cookies or URL-writing? Following the Servlet API 2.3, the third way to track sessions is by using the SSL-Layer to hold the ID. I have tried that out with my installation (Apache 2.0.47, mod_jk2, Tomcat 5.5.4) and followed the configuration hints about mod_jk and ssl. However, using form-based authentication, the server seems not to save any session id as an attribute, ssl or anything. In Bugzilla there was something about using request.getAttribute(javax.servlet.request.key_size) which would activate another attribute which one should get with request.getAttribute(javax.servlet.request.ssl_session). I tried that out - no effect. Does someone use session tracking under SSL with a similar configuration like mine above? How do you set/access the session id and get hold of the Session (or SSLSession)? Thank you in advance, Oliver Schönwald University of Hagen, Germany - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
${user.home} in catalina.properties not working
Hello,
why does the use of references like ${user.home} not work while the
reference ${catalina.home} and ${catalina.base} is usable in the
.catalina.properties-file?
Greetings,
Oliver Schoenwald
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat arbitrarily freezes
Hi! five days after my first question and no answer in sight. To bad. So far, we have switched from JDK 1.4.2 to JDK 1.5 and from Tomcat 5.0.27 to 5.5.4 and the problem persists. However, while under JDK 1.4.2 it was always the thread with id #2 under JDK 1.5 it is still the thread VM Thread, but now under id #4. Using the better debugging features of JDK 1.5 (jstack, jmap) we could pin down the problem in more detail: whenever the problem starts, the output of jstack and jmap shows that these debugging-tools have more and more problems to give information about certain memory areas. When the problem reaches its climax, a bug number of memory areas are marked by jstack with an Error occurred during stack walking:-Message or by jmap with UnmappedAddressException. You see, at the moment we are only guessing what problem we have here. Maybe someone has an idea how to analyze the problem more properly or even know how to solve it (without changing some of the components like using another servlet container engine or another JVM). Thank you for any help, Oliver Schoenwald University of Hagen Germany Oliver Schoenwald wrote: Our system configuration is as follows: SUN Fire 240 with 2 cpus at 1.28 GHz (Sparc-3) 8 GB RAM Solaris 9 (with actual patches) All requests are handled via Apache 2.0.52 with mod_ssl and using mod_jk2. The system works well most of the time, but seemingly randomly the catalina process starts to use up more and more cpu performance without actually doing anything useful! Memory usage stays normal/stable, so we analyzed the process and found out the following: - The cpu performance is used up primarily by the thread VM Thread. - This Thread is running nothing else but synchronization primitives, which where called very fast an in high numbers without reading or writing anything (as if it is in some kind of endless loop of doing nothing). - The effect (and an symptome which can be monitored repeatedly) is that the number of threads that the catalina process is using rises with every new request, because no thread gets enough cpu power to come to an end. VM Thread is taking away anything after a short period of time. We monitored the machine with prstat -L to see when the cpu usage of the catalina process rose to a unusual high value (5% at average, rising up to about 60% when VM Thread got into its frenzy). So we could see that one single lwp was going into the high cpu usage. As soon as we could see the rise in cpu usage we used pstack to find out which thread is responsible for the lwp-id that was shown by prstat -L. Then, we used kill -3 to create a thread-dump of the catalina-process and searched for the thread-number that was stated by pstack. That thread-dump showed us that the thread called VM Thread seems to be the problematic thread. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat arbitrarily freezes
Hello, we are using Tomcat 5.0.27 to provide the eLearning environment of our University. Our system configuration is as follows: SUN Fire 240 with 2 cpus at 1.28 GHz (Sparc-3) 8 GB RAM Solaris 9 (with actual patches) All requests are handled via Apache 2.0.52 with mod_ssl and using mod_jk2. The system works well most of the time, but seemingly randomly the catalina process starts to use up more and more cpu performance without actually doing anything useful! Memory usage stays normal/stable, so we analyzed the process and found out the following: - The cpu performance is used up primarily by the thread VM Thread. - This Thread is running nothing else but synchronization primitives, which where called very fast an in high numbers without reading or writing anything (as if it is in some kind of endless loop of doing nothing). - The effect (and an symptome which can be monitored repeatedly) is that the number of threads that the catalina process is using rises with every new request, because no thread gets enough cpu power to come to an end. VM Thread is taking away anything after a short period of time. To come to this information, we did the following: We monitored the machine with prstat -L to see when the cpu usage of the catalina process rose to a unusual high value (5% at average, rising up to about 60% when VM Thread got into its frenzy). So we could see that one single lwp was going into the high cpu usage. As soon as we could see the rise in cpu usage we used pstack to find out which thread is responsible for the lwp-id that was shown by prstat -L. Then, we used kill -3 to create a thread-dump of the catalina-process and searched for the thread-number that was stated by pstack. That thread-dump showed us that the thread called VM Thread seems to be the problematic thread. As far as we found out that problems occured several times with Tomcat 5 for other users in the world. However, so far no one offered an explanation what is going wrong there and what could be done to avoid that problem. We now have prepared a monitoring service that kills and restarts the catalina engine as soon as the problem occurs, but that solution is not a good one. Any suggestions of how to solve the problem are very, very welcome. If you need more information or have any idea how we should analyze the situation more properly, I would be happy to hear of it. Thank you in advance, Oliver Schoenwald FernUniversitaet Hagen Germany - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuring Tomcat 4.1.18 to handle 401 http errors
Hi Yoav, if I add this to the deployment description the my401ProcessingServlet would be called after an error-code 401 occured. But as this servlet is part of the container, too, it won't be able to send the same error 401 to the client - the container would catch this error and call my401ProcessingServlet again and again. And this error is necessary because only then the browser knows that he has to repeat the authentication. (What we *want* to do is to send the 401 error back to the client so that the browser is forced to repeat the authentication (popping up the login window) to allow the user to change his actual login. The joke is, that this actually worked under Tomcat 3.2 and with the former Servlet API 2.2, but not under Tomcat 4.1.18 and the Servlet API 2.3.). In other words: it seems that I can *not* do whatever I want under the new Servlet API 2.3, because the new tomcat engine masks all errors = 400 to a self-constructed html-page. Only during the authentication-phase of the realm the errors like 401 are send to the client normally. I still hope that there is a standard-conform way for servlets to force the container to send http errors to the client - or at least to inform the authentication realm that the current authentication should be invalidated and repeated (without automatically accepting the already used authentication data). Oliver Schönwald FernUniversität Hagen - LVU Entwicklungsgruppe University Hagen - Education and Knowledge Space: Virtual University, Development Task Force Shapira, Yoav wrote: Howdy, How about adding this to your web.xml: error-page error-code401/error-code location/my401ProcessingServlet/location /error-page Then do whatever you want in the servlet you map to the /my401ProcessingServlet url-pattern. Yoav Shapira Millennium ChemInformatics -Original Message- From: Oliver Schoenwald [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 4:18 AM To: Tomcat Users List Subject: Configuring Tomcat 4.1.18 to handle 401 http errors Good morning! some days ago I already asked a question regarding this context, but I had some time to dive a bit into the Servlet API 2.3 Specification. So far, it seems that the specification states that the container, not the servlet, is the layer attached to the client. And the container, not the servlet, controls, which and how any http errors created by a servlet within the container are handled, mapped and sent back to the client. Some digging in the catalina source code retrieved that in HttpResponseBase.java there is a method finishResponse where the handling of every HTTP error = 400 is hard-coded to be transformed into a simple, valid html-page with a plainly written error summary. However, we need the http error 401 to be send 'as is' to the client. It doesn't have to be directly, but the container should not catch this error and create an html page out of it. Does someone know how I can achieve this? Or has the Servlet API changed the communication protocol so far that this is just no longer possible without violating the standard? In that case, how SHOULD a servlet invalidate the current authentication so that the currently buffered authentication data (buffered by the client/browser) are no longer accepted and the browser is forced to ask the user again for authentication? Thank you in advance, Oliver Schönwald - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Schönwald, Diplom-Informatiker Entwicklungsgruppe Lernraum Virtuelle Universität - FernUniversität Hagen Universitätsstr.21/AVZ - 58084 Hagen Fon: +49 2331 987 1721 - Fax: +49 2331 987 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Configuring Tomcat 4.1.18 to handle 401 http errors
Good morning! some days ago I already asked a question regarding this context, but I had some time to dive a bit into the Servlet API 2.3 Specification. So far, it seems that the specification states that the container, not the servlet, is the layer attached to the client. And the container, not the servlet, controls, which and how any http errors created by a servlet within the container are handled, mapped and sent back to the client. Some digging in the catalina source code retrieved that in HttpResponseBase.java there is a method finishResponse where the handling of every HTTP error = 400 is hard-coded to be transformed into a simple, valid html-page with a plainly written error summary. However, we need the http error 401 to be send 'as is' to the client. It doesn't have to be directly, but the container should not catch this error and create an html page out of it. Does someone know how I can achieve this? Or has the Servlet API changed the communication protocol so far that this is just no longer possible without violating the standard? In that case, how SHOULD a servlet invalidate the current authentication so that the currently buffered authentication data (buffered by the client/browser) are no longer accepted and the browser is forced to ask the user again for authentication? Thank you in advance, Oliver Schönwald - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 4.1.18: How to send HTTP errors from servlets
Hello,
we have updated from Tomcat 3.2.4 to 4.1.8 and now have problems with
one of our servlets.
Under 3.2.4, this servlet send an HTTP_UNAUTHORIZED under certain
circumstances and the
Browser popped up his Login-Windows. Now, under 4.1.8, the engine
catches this error and
wraps an html-page around it, delivering a valid html-page instead of
the HTTP-error created
by the servlet using the sendError-Method of HttpServlet.Response.
So far I was not able to find out by what configuration or mechanism the
engine catches such
errors and wraps its own html-output around it. We installed the engine
as binary under Linux
and added our own authentication Realm and a Valve to do some
after-work-cleansing.
Can I de-activate it ('it' = the wrapping of http-error responses as
html-pages)? How? Would this be
ok or bad?
Can I configure it to allow errors send by the servlet to be given
straight to the client? How?
Do I have to use another method to deliver HTTP-errors instead of the
standard servlet API?
Thank you in advance,
Oliver Schönwald
--
Oliver Schönwald, Diplom-Informatiker
Entwicklungsgruppe Lernraum Virtuelle Universität - FernUniversität Hagen
Universitätsstr.21/AVZ - 58084 Hagen
Fon: +49 2331 987 1721 - Fax: +49 2331 987
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
