RE: Question on Admin WebApp in Tomcat 6.0
Ritu, You might want to take a look at Lambda Probe, a freeware 'manager' application, which is like Tomcat manager on steriods! http://www.lambdaprobe.com/ - Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 19, 2006 12:06 AM To: users@tomcat.apache.org Subject: Question on Admin WebApp in Tomcat 6.0 Hi, I was taking a look at Tomcat 6.0. The downloads did not have a separate WAR for the Admin WebApp and the Core download also did not include the Admin WebApp. Could someone please let me know from where can I download the Admin WebApp for Tomcat 6.0? I am primarily interested in understanding the difference in approach between the Admin WebApp of 5.5 and 6.0. Also I would like to understand by how much would the underlying Catalina MBeans be changed in 6.0 (if at all they are changed). Any responses would be greatly appreciated. Tomcat developers list for 6.0 has Amy Roh assigned to Admin WebApp. So Amy your response would be very much appreciated. Thanks in advance. Thanks and Regards, Ritu Kedia - This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: On Tomcat 5.5.9, can't flush the buffer or reduce buffer size 8192
Thanks Tim.
out.flush() wasn't doing anything unless there was already 8KB in the
buffer.
But, the JSP page directive helped:
Before setting the JSP page directive, the pre-compiled .java file that
Tomcat was creating had...
pageContext = _jspxFactory.getPageContext(this, request, response,
ErrorPage.jsp, true, 8192, true);
...and now, with [EMAIL PROTECTED] buffer=1kb%, it uses...
pageContext = _jspxFactory.getPageContext(this, request, response,
ErrorPage.jsp, true, 1024, true);
It looks like the buffer can only be specified in 1kb increments, but a 1KB
keep-alive being sent every 30 seconds is better than an 8KB keep-alive.
Is there a way to make the JSP page directive conditional?
Basically, I only want to set the buffer to 1KB for certain users of my
application.
I tried...
%
if (useSmallBuffer==true) {
%[EMAIL PROTECTED] buffer=1kb%%
}
%
...but this doesn't work (can't mix directives and scripting elements).
Any ideas?
Thanks,
Richard
-Original Message-
From: Tim Funk [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 19, 2006 6:53 AM
To: Tomcat Users List
Subject: Re: On Tomcat 5.5.9, can't flush the buffer or reduce buffer size
8192
JSP's also have a buffer too. To make it smaller or eliminate it:
[EMAIL PROTECTED] buffer='none'%
or use out.flush() instead or response.flushBuffer()
-Tim
Richard Mundell wrote:
No one replied, so in the hope someone might have the answer to this,
here's a repost... :-)
-Original Message-
From: Richard Mundell [mailto:[EMAIL PROTECTED]
Sent: Friday, December 15, 2006 3:37 PM
To: users@tomcat.apache.org
Subject: On Tomcat 5.5.9, can't flush the buffer or reduce buffer size
8192
I'm trying to work around a timeout problem which one of my user's
proxy server has. The proxy's timeout is set to 1 minute. Should it
not receive any HTTP traffic for 1 minute it disconnects.
One of my JSPs takes 1 minute to perform processing and return results.
What I'm trying to do is...
1) Flush out HTTP headers immediately
2) (Start my database operation which takes 1 minute)
3) Write out and flush to the client a HTML comment (!--hello--)
every 10 seconds while the database operation completes to stop the
proxy timing out
4) (Database operation completes)
5) Write out results
By calling response.flushBuffer() immediately at the top of my JSP,
the HTTP headers are being written out to the TCP stream. So far, so good.
My code then, every 10 seconds, does an out.print(!-- hello --)
and a response.flushBuffer().
By using a packet sniffer I can see that although the headers get
output to the TCP stream, the body of the HTTP response does not get
written out until the very end of the execution of the JSP. The only
way I can get the buffer to flush is if I do an out.print with a
string greater than 8192 characters (the default size of the buffer).
Note that I also tried out.flush() and that doesn't work either.
As a workaround I tried to set the buffer size artificially low, but
this call is being ignored:
System.out.println(response.getBufferSize());
// buffer size of 8192 printed to stdout
response.setBufferSize(100);
// buffer size should now be 100, right?
System.out.println(response.getBufferSize());
// buffer size of 8192 still printed to stdout
setBufferSize only works if I set the buffer 8192.
I can't find any reference in the Tomcat spec to this being a
deliberate behavior, or a hard-coded minimum?
Anyone got any ideas of where I'm going wrong, or how I might get this
to work in Tomcat 5.5.9? (Note that I'm stuck at Tomcat 5.5.9 because
the later
(Apache) HTTPS implementations don't work reliably in our environment).
-
To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Tomcat 5.5.9, can't flush the buffer or reduce buffer size 8192
No one replied, so in the hope someone might have the answer to this, here's a repost... :-) -Original Message- From: Richard Mundell [mailto:[EMAIL PROTECTED] Sent: Friday, December 15, 2006 3:37 PM To: users@tomcat.apache.org Subject: On Tomcat 5.5.9, can't flush the buffer or reduce buffer size 8192 I'm trying to work around a timeout problem which one of my user's proxy server has. The proxy's timeout is set to 1 minute. Should it not receive any HTTP traffic for 1 minute it disconnects. One of my JSPs takes 1 minute to perform processing and return results. What I'm trying to do is... 1) Flush out HTTP headers immediately 2) (Start my database operation which takes 1 minute) 3) Write out and flush to the client a HTML comment (!--hello--) every 10 seconds while the database operation completes to stop the proxy timing out 4) (Database operation completes) 5) Write out results By calling response.flushBuffer() immediately at the top of my JSP, the HTTP headers are being written out to the TCP stream. So far, so good. My code then, every 10 seconds, does an out.print(!-- hello --) and a response.flushBuffer(). By using a packet sniffer I can see that although the headers get output to the TCP stream, the body of the HTTP response does not get written out until the very end of the execution of the JSP. The only way I can get the buffer to flush is if I do an out.print with a string greater than 8192 characters (the default size of the buffer). Note that I also tried out.flush() and that doesn't work either. As a workaround I tried to set the buffer size artificially low, but this call is being ignored: System.out.println(response.getBufferSize()); // buffer size of 8192 printed to stdout response.setBufferSize(100); // buffer size should now be 100, right? System.out.println(response.getBufferSize()); // buffer size of 8192 still printed to stdout setBufferSize only works if I set the buffer 8192. I can't find any reference in the Tomcat spec to this being a deliberate behavior, or a hard-coded minimum? Anyone got any ideas of where I'm going wrong, or how I might get this to work in Tomcat 5.5.9? (Note that I'm stuck at Tomcat 5.5.9 because the later (Apache) HTTPS implementations don't work reliably in our environment). Thanks, Richard - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
On Tomcat 5.5.9, can't flush the buffer or reduce buffer size 8192
I'm trying to work around a timeout problem which one of my user's proxy server has. The proxy's timeout is set to 1 minute. Should it not receive any HTTP traffic for 1 minute it disconnects. One of my JSPs takes 1 minute to perform processing and return results. What I'm trying to do is... 1) Flush out HTTP headers immediately 2) (Start my database operation which takes 1 minute) 3) Write out and flush to the client a HTML comment (!--hello--) every 10 seconds while the database operation completes to stop the proxy timing out 4) (Database operation completes) 5) Write out results By calling response.flushBuffer() immediately at the top of my JSP, the HTTP headers are being written out to the TCP stream. So far, so good. My code then, every 10 seconds, does an out.print(!-- hello --) and a response.flushBuffer(). By using a packet sniffer I can see that although the headers get output to the TCP stream, the body of the HTTP response does not get written out until the very end of the execution of the JSP. The only way I can get the buffer to flush is if I do an out.print with a string greater than 8192 characters (the default size of the buffer). Note that I also tried out.flush() and that doesn't work either. As a workaround I tried to set the buffer size artificially low, but this call is being ignored: System.out.println(response.getBufferSize()); // buffer size of 8192 printed to stdout response.setBufferSize(100); // buffer size should now be 100, right? System.out.println(response.getBufferSize()); // buffer size of 8192 still printed to stdout setBufferSize only works if I set the buffer 8192. I can't find any reference in the Tomcat spec to this being a deliberate behavior, or a hard-coded minimum? Anyone got any ideas of where I'm going wrong, or how I might get this to work in Tomcat 5.5.9? (Note that I'm stuck at Tomcat 5.5.9 because the later (Apache) HTTPS implementations don't work reliably in our environment). Thanks, Richard - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Mini HOW-TO: Tomcat as a service on Windows Server 2003 64-bit edition
Dear all, While Tomcat will run happily on a 64-bit edition of Windows by running it directly through a 64-bit build of Java, the native Windows Service support which is bundled with Tomcat 5.5.x is presently 32-bit only. The reason to run Tomcat in a 64-bit environment is to run with large memory allocations (we have the requirement to run with around 4GB of heap space). At best you can squeeze about 1.5GB of heap allocation in a Windows 32-bit environment. To run larger than that you'll need a 64-bit CPU and OS. There's a couple of outstanding 'bugzilla' tickets (35869 39327) requesting this support but the Tomcat developers obviously haven't had a chance to build it into the core package yet. So, in the meantime, for anyone attempting to run Tomcat in 64-bit mode in Windows so save you the pain and extensive Googling to find a solution, here's a (very) brief HOW-TO. (Note that I've got this working on Windows 2003 Server Standard 64-bit edition on an Intel chipset - I'd imagine the same instructions would work fine on AMD environments and XP 64-bit). 1) Download and install the 64 bit edition of Java for Windows 2) Download and install the 32 bit version of Tomcat 5.5.x for Windows 3) Recompile 'procrun' (which is the binary $CATALINA_ROOT/bin/Tomcat5.exe in the Windows distribution) using the patch listed in Bugzilla ticket 39327 (http://issues.apache.org/bugzilla/show_bug.cgi?id=39327) and replace Tomcat5.exe with the newly compiled prunsrv.exe. 4) Add the registry keys to Windows which are listed at the end of this email (don't forget to adjust them to use your server's paths for the JVM and Tomcat). 5) Using regedit, edit the HKLM\SOFTWARE\Apache Software Foundation\Procrun 2.0\Tomcat5\Parameters\Java\Options and adjust for memory settings appropriate to your environment. 6) Start (or restart) the Apache Tomcat service. Note that although you can stop/start the Tomcat service via the bundled Tomcat service helper, if you need to change its configuration you will need to manually edit the registry key mentioned in step 5. Of course, the hardest part of this (for non-developers) is recompiling procrun. I'd be very happy to mail you a copy of the compiled binary (for Intel 64-bit Xeon and AMD 64-bit chipsets) that the contributor of the patch in ticket 39237 very kindly provided for me. This is intended as a stop-gap while the Tomcat developers implement this into the core Windows distribution. Good luck! Richard ___ Richard Mundell The Roberts Group Market Data Expertise that FITS. www.trgrp.com -- [HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 2.0\Tomcat5\Parameters\Java] Jvm=C:\\jdk\\jre\\bin\\server\\jvm.dll Classpath=C:\\tomcat\\bin\\bootstrap.jar Options=hex(7):2d,00,44,00,63,00,61,00,74,00,61,00,6c,00,69,00,6e,00,61,00 ,\ 2e,00,68,00,6f,00,6d,00,65,00,3d,00,43,00,3a,00,5c,00,74,00,72,00,67,00,5c,\ 00,66,00,69,00,74,00,73,00,77,00,65,00,62,00,5c,00,74,00,6f,00,6d,00,63,00,\ 61,00,74,00,00,00,2d,00,44,00,6a,00,61,00,76,00,61,00,2e,00,65,00,6e,00,64,\ 00,6f,00,72,00,73,00,65,00,64,00,2e,00,64,00,69,00,72,00,73,00,3d,00,43,00,\ 3a,00,5c,00,74,00,72,00,67,00,5c,00,66,00,69,00,74,00,73,00,77,00,65,00,62,\ 00,5c,00,74,00,6f,00,6d,00,63,00,61,00,74,00,5c,00,63,00,6f,00,6d,00,6d,00,\ 6f,00,6e,00,5c,00,65,00,6e,00,64,00,6f,00,72,00,73,00,65,00,64,00,00,00,2d,\ 00,44,00,6a,00,61,00,76,00,61,00,2e,00,69,00,6f,00,2e,00,74,00,6d,00,70,00,\ 64,00,69,00,72,00,3d,00,43,00,3a,00,5c,00,74,00,72,00,67,00,5c,00,66,00,69,\ 00,74,00,73,00,77,00,65,00,62,00,5c,00,74,00,6f,00,6d,00,63,00,61,00,74,00,\ 5c,00,74,00,65,00,6d,00,70,00,00,00,2d,00,44,00,6a,00,61,00,76,00,61,00,2e,\ 00,75,00,74,00,69,00,6c,00,2e,00,6c,00,6f,00,67,00,67,00,69,00,6e,00,67,00,\ 2e,00,6d,00,61,00,6e,00,61,00,67,00,65,00,72,00,3d,00,6f,00,72,00,67,00,2e,\ 00,61,00,70,00,61,00,63,00,68,00,65,00,2e,00,6a,00,75,00,6c,00,69,00,2e,00,\ 43,00,6c,00,61,00,73,00,73,00,4c,00,6f,00,61,00,64,00,65,00,72,00,4c,00,6f,\ 00,67,00,4d,00,61,00,6e,00,61,00,67,00,65,00,72,00,00,00,2d,00,58,00,58,00,\ 3a,00,4d,00,61,00,78,00,50,00,65,00,72,00,6d,00,53,00,69,00,7a,00,65,00,3d,\ 00,32,00,35,00,36,00,6d,00,00,00,2d,00,58,00,58,00,3a,00,52,00,65,00,73,00,\ 65,00,72,00,76,00,65,00,64,00,43,00,6f,00,64,00,65,00,43,00,61,00,63,00,68,\ 00,65,00,53,00,69,00,7a,00,65,00,3d,00,31,00,32,00,38,00,6d,00,00,00,2d,00,\ 58,00,6d,00,78,00,33,00,30,00,37,00,32,00,6d,00,00,00,00,00 JvmMs=dword: JvmMx=dword: JvmSs=dword: [HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 2.0\Tomcat5\Parameters\Log] Path=C:\\tomcat\\logs StdError=auto StdOutput=auto Level=Error [HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 2.0\Tomcat5\Parameters\Start] Class=org.apache.catalina.startup.Bootstrap Params=hex(7):73,00,74,00,61,00,72,00,74,00,00,00,00,00 Mode=jvm
RE: Tray Icon
Mark, If you close the icon you can simply re-run the monitoring application: $CATALINA_ROOT/bin/tomcat5w.exe. Richard ___ Richard Mundell The Roberts Group Market Data Expertise that FITS. www.trgrp.com -Original Message- From: Mark Gladstone [mailto:[EMAIL PROTECTED] Sent: Monday, June 05, 2006 2:55 PM To: users@tomcat.apache.org Subject: Tray Icon Hi, I've installed Tomcat 5.5.17 and the admin package. Yes, the admin docs state that the tray icon will appear if I choose to start Tomcat after installation; and that I will lose it later. It is a handy way to start/stop Tomcat. Is there any way to get it back? I've checked FAQs; if I missed the answer that was there, I apologize. Thanks, Mark Gladstone - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tray Icon
I'll take this off-line with Mark. -Original Message- From: Mark Gladstone [mailto:[EMAIL PROTECTED] Sent: Monday, June 05, 2006 3:39 PM To: Tomcat Users List Cc: Richard Mundell Subject: Re: Tray Icon Richard, Thank your reply. This was my first-ever question to the forum, and I hope I'm replying in the correct manner. Bringing up Apache Tomcat Properties using tomcat5w.exe, the only property that seems to make sense is Log On. The default radio button set was Local System Account. Under that, there was a checkbox Allow service to interact with desktop, which was unchecked. I checked the box, clicked on apply and ok. This had no effect. Back to square 1? Best regards, Mark Richard Mundell wrote: Mark, If you close the icon you can simply re-run the monitoring application: $CATALINA_ROOT/bin/tomcat5w.exe. Richard ___ Richard Mundell The Roberts Group Market Data Expertise that FITS. www.trgrp.com -Original Message- From: Mark Gladstone [mailto:[EMAIL PROTECTED] Sent: Monday, June 05, 2006 2:55 PM To: users@tomcat.apache.org Subject: Tray Icon Hi, I've installed Tomcat 5.5.17 and the admin package. Yes, the admin docs state that the tray icon will appear if I choose to start Tomcat after installation; and that I will lose it later. It is a handy way to start/stop Tomcat. Is there any way to get it back? I've checked FAQs; if I missed the answer that was there, I apologize. Thanks, Mark Gladstone - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Redirecting Root Servlet
Delete 'index.jsp' and place an 'index.htm' file in the ROOT directory containing your redirect. If you look in web.xml (in the Tomcat conf directory) you'll be able to configure the order of 'welcome' pages that Tomcat will serve if the user browses to the root of your web server. Richard ___ Richard Mundell The Roberts Group Market Data Expertise that FITS. www.trgrp.com -Original Message- From: Khawaja Shams [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 04, 2006 7:19 PM To: Tomcat Users List Subject: Redirecting Root Servlet Hello, I would like the default application path to send a redirect to our homepage (a site that is not running on tomcat). I tried editing index.jspinside the ROOT folder, but I found out that this particular page is precompiled at build time and will not get recompiled if any changes are made. Is there a quick fix to put a redirect in the root application so that it sends you to a different page. For example http://myTomcatInstance:8080/ should redirect to http://www.google.com Is it possible to do this without creating another application and giving it the ROOT context? I am using Tomcat 5.5.15. Thanks in advance for your help. Regards, Khawaja Shams - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOST] Tomcat 5.5.15 - HTTPS hanging and intermittent Page Cannot be Displayed problems
Apologies for the repost but I sent this last week but didn't get any replies. In the hope that the people with the answers on this might've missed it, I'm trying again... ;-) _ From: Richard Mundell [mailto:[EMAIL PROTECTED] Sent: Friday, March 31, 2006 11:33 AM To: 'users@tomcat.apache.org' Subject: Tomcat 5.5.15 - HTTPS hanging and intermittent Page Cannot be Displayed problems We upgraded our internet-facing web server from Tomcat 5.5.9 to 5.5.15 this weekend and have run into a number of intermittent connectivity problems which have resulted in rolling back to 5.5.9. We use the Tomcat HTTPS connector (without an intermediate web server between the clients and Tomcat) with all of the default configuration. Issue 1: A couple of our clients have experienced intermittent connectivity problems (where approximately 1 out of every 20 page loads results in an immediate Page Cannot Be Displayed error in Internet Explorer - it appears that Tomcat immediately rejects the connection). Issue 2: Also, during peak loading (although we're only talking about 30 to 40 concurrent users here) Tomcat appears to hang for a while and make new connections wait for up to 1 minute before returning a page. Throughout this time processor load has been consistently 20%. (The server is a dual Xeon processor, dual core machine, running Windows 2003 Server). The first problem we've seen before when we used to use Apache (with the JK connector) to deliver the HTTPS pages - I suspect the compatibility with Apache/OpenSSL's implementation of SSL and Internet Explorer's implementation of SSL are still slightly incompatible. (I believe this is a known issue on a Windows platform but has never been resolved). The second problem (with Tomcat not responding to new HTTPS requests quickly under moderate load) is new on me. I'm not really able to submit this as a bug to the Tomcat team as out-of-hours we've been unable to recreate this (even simulating a high load using JMeter), and the Page Cannot Be Displayed issue only occurs with certain brands of proxy server (Secure Computing's Sidewinder seems particuiarly sensitive to this). Also, there's no errors The only conclusion I can draw right now is that if you want to use Tomcat to deliver HTTPS content from a Windows-based server, stick with Tomcat 5.5.9. Has anyone else had a similar experience? Richard ___ Richard Mundell The Roberts Group Market Data Expertise that FITS. +1 212 499 2680 x20 (office) www.trgrp.com
RE: [REPOST] Tomcat 5.5.15 - HTTPS hanging and intermittent Page Cannot be Displayed problems
Hi David, There's nothing in any of the log indicating any problems. We uninstalled Tomcat 5.5.15 on the server and installed 5.5.9 with identical configuration (with the exception of reconfiguring the HTTPS connector to use the Java Key Store rather than OpenSSL-style certificate and key). No other response time issues with other servers hosted on the network (which use the same internet connection and firewalls/routers). Puzzling huh? ;-) - Richard -Original Message- From: David Smith [mailto:[EMAIL PROTECTED] Sent: Monday, April 03, 2006 2:09 PM To: Tomcat Users List Subject: Re: [REPOST] Tomcat 5.5.15 - HTTPS hanging and intermittent Page Cannot be Displayed problems Given you've indicated all the headaches occurred in the move from 5.5.9 to 5.5.15, you might want to take a look at the change log in relation to your environment. Are your connectors configured the same (acceptCount, maxThreads)? Beyond that, issue 1 implies something else may be causing issues on the network and interfering with your server's operation -- especially when you can't reproduce it at any other time. Maybe something is causing high traffic to the point of denial of service. Do any other services have issues with dropped connection or delayed response during the same time? --David Richard Mundell wrote: Apologies for the repost but I sent this last week but didn't get any replies. In the hope that the people with the answers on this might've missed it, I'm trying again... ;-) _ From: Richard Mundell [mailto:[EMAIL PROTECTED] Sent: Friday, March 31, 2006 11:33 AM To: 'users@tomcat.apache.org' Subject: Tomcat 5.5.15 - HTTPS hanging and intermittent Page Cannot be Displayed problems We upgraded our internet-facing web server from Tomcat 5.5.9 to 5.5.15 this weekend and have run into a number of intermittent connectivity problems which have resulted in rolling back to 5.5.9. We use the Tomcat HTTPS connector (without an intermediate web server between the clients and Tomcat) with all of the default configuration. Issue 1: A couple of our clients have experienced intermittent connectivity problems (where approximately 1 out of every 20 page loads results in an immediate Page Cannot Be Displayed error in Internet Explorer - it appears that Tomcat immediately rejects the connection). Issue 2: Also, during peak loading (although we're only talking about 30 to 40 concurrent users here) Tomcat appears to hang for a while and make new connections wait for up to 1 minute before returning a page. Throughout this time processor load has been consistently 20%. (The server is a dual Xeon processor, dual core machine, running Windows 2003 Server). The first problem we've seen before when we used to use Apache (with the JK connector) to deliver the HTTPS pages - I suspect the compatibility with Apache/OpenSSL's implementation of SSL and Internet Explorer's implementation of SSL are still slightly incompatible. (I believe this is a known issue on a Windows platform but has never been resolved). The second problem (with Tomcat not responding to new HTTPS requests quickly under moderate load) is new on me. I'm not really able to submit this as a bug to the Tomcat team as out-of-hours we've been unable to recreate this (even simulating a high load using JMeter), and the Page Cannot Be Displayed issue only occurs with certain brands of proxy server (Secure Computing's Sidewinder seems particuiarly sensitive to this). Also, there's no errors The only conclusion I can draw right now is that if you want to use Tomcat to deliver HTTPS content from a Windows-based server, stick with Tomcat 5.5.9. Has anyone else had a similar experience? Richard ___ Richard Mundell The Roberts Group Market Data Expertise that FITS. +1 212 499 2680 x20 (office) www.trgrp.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [REPOST] Tomcat 5.5.15 - HTTPS hanging and intermittent Page Cannot be Displayed problems
In 5.5.15 we switched to using the (ever-so-well-documented) APR native library so I suspect it's the OpenSSL code in the APR library which is causing the problem. -Original Message- From: David Smith [mailto:[EMAIL PROTECTED] Sent: Monday, April 03, 2006 2:18 PM To: Tomcat Users List Subject: Re: [REPOST] Tomcat 5.5.15 - HTTPS hanging and intermittent Page Cannot be Displayed problems When I said change log, I meant the text file that lists out all the changes the developers made between releases. What issues they fixed and what not. Is your install using the APR native library that I believe was introduced somewhere around 5.5.15? --David Richard Mundell wrote: Hi David, There's nothing in any of the log indicating any problems. We uninstalled Tomcat 5.5.15 on the server and installed 5.5.9 with identical configuration (with the exception of reconfiguring the HTTPS connector to use the Java Key Store rather than OpenSSL-style certificate and key). No other response time issues with other servers hosted on the network (which use the same internet connection and firewalls/routers). Puzzling huh? ;-) - Richard -Original Message- From: David Smith [mailto:[EMAIL PROTECTED] Sent: Monday, April 03, 2006 2:09 PM To: Tomcat Users List Subject: Re: [REPOST] Tomcat 5.5.15 - HTTPS hanging and intermittent Page Cannot be Displayed problems Given you've indicated all the headaches occurred in the move from 5.5.9 to 5.5.15, you might want to take a look at the change log in relation to your environment. Are your connectors configured the same (acceptCount, maxThreads)? Beyond that, issue 1 implies something else may be causing issues on the network and interfering with your server's operation -- especially when you can't reproduce it at any other time. Maybe something is causing high traffic to the point of denial of service. Do any other services have issues with dropped connection or delayed response during the same time? --David Richard Mundell wrote: Apologies for the repost but I sent this last week but didn't get any replies. In the hope that the people with the answers on this might've missed it, I'm trying again... ;-) _ From: Richard Mundell [mailto:[EMAIL PROTECTED] Sent: Friday, March 31, 2006 11:33 AM To: 'users@tomcat.apache.org' Subject: Tomcat 5.5.15 - HTTPS hanging and intermittent Page Cannot be Displayed problems We upgraded our internet-facing web server from Tomcat 5.5.9 to 5.5.15 this weekend and have run into a number of intermittent connectivity problems which have resulted in rolling back to 5.5.9. We use the Tomcat HTTPS connector (without an intermediate web server between the clients and Tomcat) with all of the default configuration. Issue 1: A couple of our clients have experienced intermittent connectivity problems (where approximately 1 out of every 20 page loads results in an immediate Page Cannot Be Displayed error in Internet Explorer - it appears that Tomcat immediately rejects the connection). Issue 2: Also, during peak loading (although we're only talking about 30 to 40 concurrent users here) Tomcat appears to hang for a while and make new connections wait for up to 1 minute before returning a page. Throughout this time processor load has been consistently 20%. (The server is a dual Xeon processor, dual core machine, running Windows 2003 Server). The first problem we've seen before when we used to use Apache (with the JK connector) to deliver the HTTPS pages - I suspect the compatibility with Apache/OpenSSL's implementation of SSL and Internet Explorer's implementation of SSL are still slightly incompatible. (I believe this is a known issue on a Windows platform but has never been resolved). The second problem (with Tomcat not responding to new HTTPS requests quickly under moderate load) is new on me. I'm not really able to submit this as a bug to the Tomcat team as out-of-hours we've been unable to recreate this (even simulating a high load using JMeter), and the Page Cannot Be Displayed issue only occurs with certain brands of proxy server (Secure Computing's Sidewinder seems particuiarly sensitive to this). Also, there's no errors The only conclusion I can draw right now is that if you want to use Tomcat to deliver HTTPS content from a Windows-based server, stick with Tomcat 5.5.9. Has anyone else had a similar experience? Richard ___ Richard Mundell The Roberts Group Market Data Expertise that FITS. +1 212 499 2680 x20 (office) www.trgrp.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Tomcat 5.5.15 - HTTPS hanging and intermittent Page Cannot be Displayed problems
We upgraded our internet-facing web server from Tomcat 5.5.9 to 5.5.15 this weekend and have run into a number of intermittent connectivity problems which have resulted in rolling back to 5.5.9. We use the Tomcat HTTPS connector (without an intermediate web server between the clients and Tomcat) with all of the default configuration. Issue 1: A couple of our clients have experienced intermittent connectivity problems (where approximately 1 out of every 20 page loads results in an immediate Page Cannot Be Displayed error in Internet Explorer - it appears that Tomcat immediately rejects the connection). Issue 2: Also, during peak loading (although we're only talking about 30 to 40 concurrent users here) Tomcat appears to hang for a while and make new connections wait for up to 1 minute before returning a page. Throughout this time processor load has been consistently 20%. (The server is a dual Xeon processor, dual core machine, running Windows 2003 Server). The first problem we've seen before when we used to use Apache (with the JK connector) to deliver the HTTPS pages - I suspect the compatibility with Apache/OpenSSL's implementation of SSL and Internet Explorer's implementation of SSL are still slightly incompatible. (I believe this is a known issue on a Windows platform but has never been resolved). The second problem (with Tomcat not responding to new HTTPS requests quickly under moderate load) is new on me. I'm not really able to submit this as a bug to the Tomcat team as out-of-hours we've been unable to recreate this (even simulating a high load using JMeter), and the Page Cannot Be Displayed issue only occurs with certain brands of proxy server (Secure Computing's Sidewinder seems particuiarly sensitive to this). Also, there's no errors The only conclusion I can draw right now is that if you want to use Tomcat to deliver HTTPS content from a Windows-based server, stick with Tomcat 5.5.9. Has anyone else had a similar experience? Richard ___ Richard Mundell The Roberts Group Market Data Expertise that FITS. +1 212 499 2680 x20 (office) www.trgrp.com
Question: Accessing connector/connection thread statistics from within a JSP (plus example memory monitoring code)
We have a application monitoring page which includes, amongst other
application-specific data, Java memory usage statistics. (To share with the
group I've included the example code below!)
I want to include connection statistics for each connector, in particular
the information that the manager app shows (number of connection, threads in
use, number kept alive, etc) and also (if it's stored somewhere) the peak
number of connections since Tomcat was started. Does anyone have some
example JSP code they could share?
Thanks
Richard
___
Richard Mundell
The Roberts Group
Market Data Expertise that FITS.
+1 212 499 2680 x20 (office)
www.trgrp.com
EXAMPLE CODE FOR MEMORY MONITORING:
%@ page import=java.sql.* %
%@ page import=java.util.* %
%@ page import=java.lang.management.* %
%
// MEMORY USAGE
Iterator iter2 = ManagementFactory.getMemoryPoolMXBeans().iterator();
float max;
float used;
float heapmax=0;
float heapused=0;
float heappeak=0;
String paddedName=;
String memoryString=;
String heapMemory=;
int problem=0;
while (iter2.hasNext()) {
MemoryPoolMXBean item2 = (MemoryPoolMXBean) iter2.next();
if (item2.getType().toString().toUpperCase().equals(NON-HEAP MEMORY)) {
paddedName=item2.getName().toString();
while (paddedName.length()18) {
paddedName+= ;
}
memoryString+=paddedName + \t;
max = new Long(item2.getUsage().getMax()).floatValue();
used = new Long(item2.getUsage().getUsed()).floatValue();
memoryString+=new Float(max/1048576).shortValue() + MB max, ;
memoryString+=new Float((max-used)/1048576).shortValue() + MB;
memoryString+=( + new Float(((max-used)/max)*100).shortValue()+%)
free, ;
memoryString+=new
Float(item2.getPeakUsage().getUsed()/1048576).shortValue() +MB peak
usage\n;
if (new Float(((max-used)/max)*100).shortValue()20) {
problem=1;
memoryString+=FONT COLOR=REDBWARNING: + item2.getName()+ IS
20%/FONT\n;
}
} else {
heapmax += item2.getUsage().getMax();
heapused += item2.getUsage().getUsed();
heappeak += item2.getPeakUsage().getUsed();
}
}
String heapmemory;
heapmemory=Main memory (heap)\t;
heapmemory+=new Float(heapmax/1048576).shortValue() + MB max, ;
heapmemory+=new Float((heapmax-heapused)/1048576).shortValue() + MB;
heapmemory+=( + new
Float(((heapmax-heapused)/heapmax)*100).shortValue()+%) free, ;
heapmemory+=new Float(heappeak/1048576).shortValue() +MB peak usage\n;
if (new Float(((heapmax-heapused)/heapmax)*100).shortValue()20) {
problem=1;
heapmemory+=FONT COLOR=REDBWARNING: Main Memory (heap) IS
20%/FONT\n;
}
memoryString=heapmemory+memoryString;
out.print(PRE + memoryString);
%
