Read-only tomcat manager app?
Is there a way to have the manager app to be read-only, so to disable stop, undeployment and reload of apps through the manager? regards Emerson - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Read-only tomcat manager app?
On 12/02/2010 09:32, emerson cargnin wrote: Is there a way to have the manager app to be read-only, so to disable stop, undeployment and reload of apps through the manager? Try adding a role that only has permission to access /html/list Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
digest algorithm in BASIC auth
Hi all, my tomcat conf has basic auth and i have a the following in web.xml login-config auth-methodBASIC/auth-method realm-nameThe HTML Application/realm-name /login-config now i´m seeing that the password during the auth is digested and has value. Authorization: Basic YW50b25pbzpwYXNzd29yZA== My problem is that i cannot understand where it comes from... I´m trying all the combination, i mean i´m digesting user:realm:password with all of the algorithms but i cannot get that value. does anyone of you can suggest me where i´m missing? thanks you all, Antonio -- View this message in context: http://old.nabble.com/digest-algorithm-in-BASIC-auth-tp27562000p27562000.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
tomcat directing
Hello I have Tomcat with Jira. Is there a way to directing so that Tomcat the link srv01\instance in srv01 redirect? I have a Windows XP Server (I know, I know win XP isn't a server edition ;) ) regards Blueberry -- View this message in context: http://old.nabble.com/tomcat-directing-tp27562019p27562019.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: digest algorithm in BASIC auth
2010/2/12 banto banto...@gmail.com: I´m trying all the combination, i mean i´m digesting user:realm:password with all of the algorithms but i cannot get that value. See RFC 2617 or at least http://en.wikipedia.org/wiki/Basic_access_authentication Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat web.xml
I have set Session-Config/session-timeout eleemnt's value in application's web.xml as 100. However, the sessions seem to timeout in the default 30 minutes. However, setting this value lesser than 30, seems to work fine. Appreciate help on this. Thanks Best Regds.- Ravi Sharda This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
What governs a URL connection timeout?
Hi all
Hoping someone can shed some light on a little puzzle I have. This
may be more a Java programming problem than a Tomcat problem so
apologies if that is the case but it's specific to a system running on
Tomcat so I'm asking here too. One of our servlets is opening a URL
connection to hit an external URL, the external URL can sometimes take
a while to respond and when that happens the URL connection throws a
socket timeout exception (see the stack trace below). What I can't
work out is what determines how long the connection waits before it
times-out, we don't set anything explicitly in our code and it doesn't
seem to be related to the servlet timeout in the connector, does
anyone know what determines the timeout length and how it can be
changed? The code is simply -
public void outputUrl(OutputStream p_out, String p_url) {
try {
URL t_url = new URL(p_url);
InputStream t_inputStream = t_url.openStream();
// Read from the input stream, and write to the output stream
byte[] l_buffer = new byte[10]; // buffer holding bytes to
be transferred
int l_nbytes = 0; // Number of bytes read
while ((l_nbytes = t_inputStream.read(l_buffer)) != -1)
p_out.write(l_buffer,0,l_nbytes);
t_inputStream.close();
}
catch (Exception e)
{
nsglog.error(String.valueOf(e), e);
}
}
The error trace is -
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:659)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:604)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:961)
at java.net.URL.openStream(URL.java:1007)
at ep.ext.outputUrl(ext.java:446)
So it's the attempt to open the input stream on the URL that is timing
out, what governs that timeout?
--
Chris Mannion
iCasework and LocalAlert implementation team
0208 144 4416
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What governs a URL connection timeout?
A swift Google for:
java url openStream timeout
reveals:
http://stuffthathappens.com/blog/2007/09/10/urlopenstream-might-leave-you-hanging/
as its first hit.
In essence: the timeout is controlled by setTimeout on UrlConnection.
On 12 February 2010 11:59, Chris Mannion chris.mann...@icasework.com wrote:
Hi all
Hoping someone can shed some light on a little puzzle I have. This
may be more a Java programming problem than a Tomcat problem so
apologies if that is the case but it's specific to a system running on
Tomcat so I'm asking here too. One of our servlets is opening a URL
connection to hit an external URL, the external URL can sometimes take
a while to respond and when that happens the URL connection throws a
socket timeout exception (see the stack trace below). What I can't
work out is what determines how long the connection waits before it
times-out, we don't set anything explicitly in our code and it doesn't
seem to be related to the servlet timeout in the connector, does
anyone know what determines the timeout length and how it can be
changed? The code is simply -
public void outputUrl(OutputStream p_out, String p_url) {
try {
URL t_url = new URL(p_url);
InputStream t_inputStream = t_url.openStream();
// Read from the input stream, and write to the output stream
byte[] l_buffer = new byte[10]; // buffer holding bytes to
be transferred
int l_nbytes = 0; // Number of bytes read
while ((l_nbytes = t_inputStream.read(l_buffer)) != -1)
p_out.write(l_buffer,0,l_nbytes);
t_inputStream.close();
}
catch (Exception e)
{
nsglog.error(String.valueOf(e), e);
}
}
The error trace is -
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:659)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:604)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:961)
at java.net.URL.openStream(URL.java:1007)
at ep.ext.outputUrl(ext.java:446)
So it's the attempt to open the input stream on the URL that is timing
out, what governs that timeout?
--
Chris Mannion
iCasework and LocalAlert implementation team
0208 144 4416
-
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: Tomcat dies suddenly
This problem continues to plague me. A quick recap so you don't have to search your memory or archives. The 10,000 foot view: new Dell T105 and T110, Slackware 13.0 (64 bit), latest Java (64 bit) and latest Tomcat. Machines only run Tomcat and a small, special purpose Java server (which I have also moved to another machine to make certain it wasn't causing any problems.) Periodically, Tomcat just dies leaving no tracks in any log that I have been able to find. The application has run on a Slackware 12.1 (32 bit) for several years without problems (except for application bugs.) I have run memTest86 for 30 hours on the T110 with no problems reported. More details: the Dell 105 has an AMD processor and (currently) 8 GB memory. The T110 has a Xeon 3440 processor and 4 GB memory. The current Java version is 1.6.0_18-b07. The current Tomcat version is 6.0.24. The servers are lightly loaded with less than 100 sessions active at any one time. All of the following trials have produced the same results: 1. Tried openSuse 64 bit. 2. Tried 32 bit Slackware 13. 3. Increased the memory in the T105 from 4GB to 6 GB and finally to 8 GB. 4. Have fiddled with the JAVA_OPTS settings in catalina.sh. The current settings are: JAVA_OPTS=-Xms512m -Xmx512m -XX:PermSize=384m -XX:MaxPermSize=384m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/tomcat/logs I can see the incremental GC effects in both catalina.out and VisualJVM. Note the fairly small (512MB) heap but watching VisualJVM indicates this is sufficient (when a failure occurs, VisualJVM will report the last amount of memory used and this is always well under the max in both heap and permGen.) More information about the failures: 1. They are clean kills as I can restart Tomcat immediately after failure and there is no port conflict. As I understand it, this implies the linux process was killed (I have manually killed the java process with kill -9 and had the same result that I have observed when the system fails) or Tomcat was shut down normally, e.g., using shutdown.sh (this always leaves tracks in catalina.out and I am not seeing any so I do not believe this is the case.) 2. They appear to be load related. On heavy processing days, the system might fail every 15 minutes but it could also run for up to 10 days without failure but with lighter processing. I have found a way to force a more frequent failure. We have four war's deployed (I will call them A, B, C and D.) They are all the same application but we use this process to enable access to different databases. A user accesses the correct application by https://xx.com/A or B, etc. A is used for production while the others have specific purposes. Thus, A is always used while the others are used periodically. If users start coming in on B, C and/or D, within hours the failure occurs (Tomcat shuts down bringing all of the users down, of course.) Note that the failure still does not happen immediately. 3. They do not appear to be caused by memory restrictions as 1) the old server had only 2 GB of memory and ran well, 2) I have tried adding memory to the new servers with no change in behavior and 3) the indications from top and the Slackware system monitor are that the system is not starved for memory. In fact, yesterday, running on the T105 with 8 GB of memory, top never reported over 6 GB being used (0 swap being used) yet it failed at about 4:00PM. 4. Most of the failures will occur after some amount of processing. We update the war's and restart the Tomcats each morning at 1:00AM. Most of the failures will occur toward the end of the day although heavy processing (or using multiple 'applications') may force it to happen earlier (the earliest failure has been around 1:00PM... it was the heaviest processing day ever.) It is almost as if there is a bucket somewhere that gets filled up and, when filled, causes the failure. (So there is no misunderstanding, there has never been an OOM condition reported anywhere that I can find.) Observations (or random musings): The fact that the failures occur after some amount of processing implies that the issue is related to memory usage, and, potentially, caused by a memory leak in the application. However, 1) I have never seen (from VisualJVM) any issue with either heap or permGen and the incremental GC's reported in catalina.out look pretty normal and 2) top, vmstat, system monitor, etc. are not showing any issues with memory. The failures look a lot like the linux OOM killer (which Mark or Chris said way back at the beginning which is now 2-3 months ago.) Does anyone have an idea where I could get information on tracking the linux signals that could cause this? Thanks, Carl - To unsubscribe,
Re: What governs a URL connection timeout?
Thanks Peter but we're not using a URLConnection, nor are we
explicitly setting any timeouts, as you can see from the code.
On 12 February 2010 12:06, Peter Crowther peter.crowt...@melandra.com wrote:
A swift Google for:
java url openStream timeout
reveals:
http://stuffthathappens.com/blog/2007/09/10/urlopenstream-might-leave-you-hanging/
as its first hit.
In essence: the timeout is controlled by setTimeout on UrlConnection.
On 12 February 2010 11:59, Chris Mannion chris.mann...@icasework.com wrote:
Hi all
Hoping someone can shed some light on a little puzzle I have. This
may be more a Java programming problem than a Tomcat problem so
apologies if that is the case but it's specific to a system running on
Tomcat so I'm asking here too. One of our servlets is opening a URL
connection to hit an external URL, the external URL can sometimes take
a while to respond and when that happens the URL connection throws a
socket timeout exception (see the stack trace below). What I can't
work out is what determines how long the connection waits before it
times-out, we don't set anything explicitly in our code and it doesn't
seem to be related to the servlet timeout in the connector, does
anyone know what determines the timeout length and how it can be
changed? The code is simply -
public void outputUrl(OutputStream p_out, String p_url) {
try {
URL t_url = new URL(p_url);
InputStream t_inputStream = t_url.openStream();
// Read from the input stream, and write to the output stream
byte[] l_buffer = new byte[10]; // buffer holding bytes to
be transferred
int l_nbytes = 0; // Number of bytes read
while ((l_nbytes = t_inputStream.read(l_buffer)) != -1)
p_out.write(l_buffer,0,l_nbytes);
t_inputStream.close();
}
catch (Exception e)
{
nsglog.error(String.valueOf(e), e);
}
}
The error trace is -
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:659)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:604)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:961)
at java.net.URL.openStream(URL.java:1007)
at ep.ext.outputUrl(ext.java:446)
So it's the attempt to open the input stream on the URL that is timing
out, what governs that timeout?
--
Chris Mannion
iCasework and LocalAlert implementation team
0208 144 4416
-
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
--
Chris Mannion
iCasework and LocalAlert implementation team
0208 144 4416
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What governs a URL connection timeout?
Chris, did you actually read the link or was that a knee-jerk
response? Notably the following, taken from between the first and
second boxed pieces of code on that page:
The openStream() method is actually just a shortcut for
openConnection().getInputStream().
... plus the source of openStream() to prove it.
So, yes, you *are* using a URLConnection internally. And... correct,
you're not setting any timeouts in your code. But you want to. That
page provides code further down that allows you to set such a timeout.
- Peter
On 12 February 2010 12:24, Chris Mannion chris.mann...@icasework.com wrote:
Thanks Peter but we're not using a URLConnection, nor are we
explicitly setting any timeouts, as you can see from the code.
On 12 February 2010 12:06, Peter Crowther peter.crowt...@melandra.com wrote:
A swift Google for:
java url openStream timeout
reveals:
http://stuffthathappens.com/blog/2007/09/10/urlopenstream-might-leave-you-hanging/
as its first hit.
In essence: the timeout is controlled by setTimeout on UrlConnection.
On 12 February 2010 11:59, Chris Mannion chris.mann...@icasework.com wrote:
Hi all
Hoping someone can shed some light on a little puzzle I have. This
may be more a Java programming problem than a Tomcat problem so
apologies if that is the case but it's specific to a system running on
Tomcat so I'm asking here too. One of our servlets is opening a URL
connection to hit an external URL, the external URL can sometimes take
a while to respond and when that happens the URL connection throws a
socket timeout exception (see the stack trace below). What I can't
work out is what determines how long the connection waits before it
times-out, we don't set anything explicitly in our code and it doesn't
seem to be related to the servlet timeout in the connector, does
anyone know what determines the timeout length and how it can be
changed? The code is simply -
public void outputUrl(OutputStream p_out, String p_url) {
try {
URL t_url = new URL(p_url);
InputStream t_inputStream = t_url.openStream();
// Read from the input stream, and write to the output stream
byte[] l_buffer = new byte[10]; // buffer holding bytes to
be transferred
int l_nbytes = 0; // Number of bytes read
while ((l_nbytes = t_inputStream.read(l_buffer)) != -1)
p_out.write(l_buffer,0,l_nbytes);
t_inputStream.close();
}
catch (Exception e)
{
nsglog.error(String.valueOf(e), e);
}
}
The error trace is -
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:659)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:604)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:961)
at java.net.URL.openStream(URL.java:1007)
at ep.ext.outputUrl(ext.java:446)
So it's the attempt to open the input stream on the URL that is timing
out, what governs that timeout?
--
Chris Mannion
iCasework and LocalAlert implementation team
0208 144 4416
-
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
--
Chris Mannion
iCasework and LocalAlert implementation team
0208 144 4416
-
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: Tomcat dies suddenly
From: Carl [mailto:c...@etrak-plus.com] Subject: Re: Tomcat dies suddenly The fact that the failures occur after some amount of processing implies that the issue is related to memory usage, and, potentially, caused by a memory leak in the application. Actually, it's looking less and less like a memory problem here. What about exhaustion of some other resource, such as a disk quota? Do the applications create any kind of log files or otherwise use increasing amounts of disk as they run? - 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 directing
From: Blueberry [mailto:sandro.lamp...@zeitag.ch] Subject: tomcat directing I have Tomcat with Jira. Is there a way to directing so that Tomcat the link srv01\instance in srv01 redirect? Have someone unfamiliar with your project read the above; can they make any sense of your question? I certainly can't. - 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
AW: 64bit Server + JDK 1.5 (64bit) + Tomcat 5.0.28?
Hello, tank you very much, we're running now the described architecture on 64 bit environment! I would now like to optimize the thread configuration of our Tomcat and therefore I would like to use the manager information like Current thread count, Current thread busy or error count: ... == Does anyone has a link / url /document where these parameters are explained in detail ? Regards, Stefan! -Ursprungliche Nachricht- Von: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Gesendet: Donnerstag, 11. Februar 2010 17:24 An: Tomcat Users List Betreff: RE: 64bit Server + JDK 1.5 (64bit) + Tomcat 5.0.28? From: Stefan Rainer [mailto:s.rai...@teamaxess.com] Subject: 64bit Server + JDK 1.5 (64bit) + Tomcat 5.0.28? BUT as far as I know, tomcat 5.0.28 is compiled for 32 bit. Tomcat is pure Java, so it's independent of architecture. If you're running Tomcat as a service on Windows, you will need to get the 64-bit version of the service wrapper (tomcat5.exe). Get it from here: http://svn.apache.org/repos/asf/tomcat/tc5.5.x/tags/TOMCAT_5_5_28/connectors /procrun/bin/amd64/ (The 5.5 tomcat5.exe will work on 5.0.) We'd like to avoid a Tomcat update at the moment! Don't wait too long - the version you're on is almost six years old and hasn't been supported for quite some time. - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: 64bit Server + JDK 1.5 (64bit) + Tomcat 5.0.28?
From: Stefan Rainer [mailto:s.rai...@teamaxess.com] Subject: AW: 64bit Server + JDK 1.5 (64bit) + Tomcat 5.0.28? I would now like to optimize the thread configuration of our Tomcat There's not much point in trying to optimize an unsupported, six-year-old version of Tomcat. Your time would be better spent upgrading to a current level, which includes significant performance improvements. - 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 dies suddenly
Chuck, Thanks for your quick reply. I don't think any of the file systems are in danger (we purposely spec'd large disks because they were cheap and we wouldn't have to deal with space shortages.) df gives: Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 76896348468464 72521680 1% / /dev/sda4 66682840 8093552 55201984 13% /usr tmpfs 4085376 0 4085376 0% /dev/shm Tomcat is in /usr/local/tomcat. We have no quotas on any of the file systems (checked with 'quotacheck' just in case some rogue quota was set.) No logs (other than the standard Tomcat logs.) tomcat/temp currently has files totaling 272K... not likely that is a problem. Thanks, Carl - Original Message - From: Caldarale, Charles R chuck.caldar...@unisys.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 8:39 AM Subject: RE: Tomcat dies suddenly From: Carl [mailto:c...@etrak-plus.com] Subject: Re: Tomcat dies suddenly The fact that the failures occur after some amount of processing implies that the issue is related to memory usage, and, potentially, caused by a memory leak in the application. Actually, it's looking less and less like a memory problem here. What about exhaustion of some other resource, such as a disk quota? Do the applications create any kind of log files or otherwise use increasing amounts of disk as they run? - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat directing
n828cl wrote: From: Blueberry [mailto:sandro.lamp...@zeitag.ch] Subject: tomcat directing I have Tomcat with Jira. Is there a way to directing so that Tomcat the link srv01\instance in srv01 redirect? Have someone unfamiliar with your project read the above; can they make any sense of your question? I certainly can't. - Chuck Okey, I'm sorry for my bad English... I try again: I have a server called srv01 on this server is tomcat running and i should make an filter which catch the incoming request and check the url, if the url contains more than http://srv01/; e.x. http://srv01/instance; then he should redirect to http://srv01;. my question is: where is the file (or which filename does this file have), where the filter are wrotten in? I hope now it's more cleare what I mean... -- View this message in context: http://old.nabble.com/tomcat-directing-tp27562019p27563977.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: tomcat directing
From: Blueberry [mailto:sandro.lamp...@zeitag.ch] Subject: RE: tomcat directing Okey, I'm sorry for my bad English... The English was fine, it was the content of the question that was lacking. if the url contains more than http://srv01/; e.x. http://srv01/instance; then he should redirect to http://srv01;. my question is: where is the file (or which filename does this file have), where the filter are wrotten in? Much better. You're still missing some details, such as the Tomcat version you're using, so we'll assume you're on a current one. You'll want your webapp deployed as ROOT (case sensitive, even on Windows), since ROOT is the default webapp. Read the servlet spec for how to specify filters in the WEB-INF/web.xml file. There's already a general purpose, highly configurable rewrite filter available to drop into any webapp, so you don't need to write your own. Look here for details: http://tuckey.org/urlrewrite/ - 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 directing
n828cl wrote: From: Blueberry [mailto:sandro.lamp...@zeitag.ch] Subject: RE: tomcat directing Okey, I'm sorry for my bad English... The English was fine, it was the content of the question that was lacking. if the url contains more than http://srv01/; e.x. http://srv01/instance; then he should redirect to http://srv01;. my question is: where is the file (or which filename does this file have), where the filter are wrotten in? Much better. You're still missing some details, such as the Tomcat version you're using, so we'll assume you're on a current one. You'll want your webapp deployed as ROOT (case sensitive, even on Windows), since ROOT is the default webapp. Read the servlet spec for how to specify filters in the WEB-INF/web.xml file. There's already a general purpose, highly configurable rewrite filter available to drop into any webapp, so you don't need to write your own. Look here for details: http://tuckey.org/urlrewrite/ - Chuck Version of my tomcat is 5.5 -- View this message in context: http://old.nabble.com/tomcat-directing-tp27562019p27564217.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
download a small file from tomcat server
I like to download a small file (C:\dir1\data.txt) from tomcat server to my local machine which is running a Prototype javascript. How to do that? Any sample code or tutorial? -- View this message in context: http://old.nabble.com/download-a-small-file-from-tomcat-server-tp27564758p27564758.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: Web application for access folder on server machine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul, On 2/11/2010 4:35 PM, Paul Chany wrote: Christopher Schultz ch...@christopherschultz.net writes: Wait, why can only some of the Windows boxes (clients) access your PC box (the server)? I would think that if you just want to have shared folders, you ought to be able to do that using standard Microsoft Windows Network File Sharing (SMB). No, not the server but the so called shared folder. You know, right click on the folder and choose Sharing and Security. Right the server here is both a physical machine (your PC box) and a service running on that machine to share files. That software uses a protocol called SMB. So, you haven't answered my question: why can only some clients connect and others not? So I must to copy my shared folders to another PC box because for those pupils who can't access my shared folders on the first PC box. Uh, that doesn't sound right. Can you explain in more detail? Why can't all clients contact the server? If they can't contact your server, now, why do you think they would be able to contact the server if it were running Tomcat? Again, not the server, but the shared folder, using Windows Explorer. The shared folder is on the server. But, when I was installed Tomcat server, then from the LAN everyone can access the Tomcat sever's homepage, using a web browser (Firefox or Internet Explorer. The problem is accessing only the shared folder and not the Tomcat server for everyone from the LAN's PC boxes. Right: what IS the problem? OK, then I will try to install on the teachers PC box Windows system an apache server, and try to setup WebDAV so my pupils can access a folder on the teacher's PC box using http. :) Is it just that you want to use HTTP instead of SMB? This seems like a lot of work for no discernible gain. WebDAV really sucks compared to SMB from the typical user's perspective. If you really want to write something like this, we can help you. But, please, first investigate your other options, first. Thanks, but I will try first the Apache WebDAV solution. :) Good luck. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1bQwACgkQ9CaO5/Lv0PDYpgCfTmznqUZ1LF717McutpBBBTgI C1MAoJE4uSFhi00T/T1n0OxUmB01It4u =2IoJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: problem with tomcat 5.5 and apache AJP
A bit late, but we made progress in identifying the culprit. It seems that, for some reason, the password we used for AJP connection was the problem. Remove the password both side and everything works happily. We will try less complicated password, assuming that some special caracters were problematic (we stayed in US ASCII range however) Le 22/01/10 14:20, André Warnier a écrit : David Delbecq wrote: Connector port=8019 protocol=AJP/1.3 request.secret=MyPass protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler redirectPort=443 /Connector and apache is configured as follow: worker.list=lbJboss,lbOld,lbTomcat,status # Define jbossBoromir # modify the host as your host IP or DNS name. worker.jbossBoromir.port=8009 worker.jbossBoromir.host=localhost worker.jbossBoromir.type=ajp13 worker.jbossBoromir.lbfactor=1 worker.jbossBoromir.prepost_timeout=1 #Not required if using ping_mode=A worker.jbossBoromir.connect_timeout=1 #Not required if using ping_mode=A worker.jbossBoromir.secret=MyPass #worker.tomcatBoromir.ping_mode=A #As of mod_jk 1.2.27 # worker.tomcatBoromir.connection_pool_size=10 (1) worker.tomcatBoromir.port=8019 worker.tomcatBoromir.host=localhost worker.tomcatBoromir.type=ajp13 worker.tomcatBoromir.lbfactor=1 worker.tomcatBoromir.prepost_timeout=1 #Not required if using ping_mode=A worker.tomcatBoromir.connect_timeout=1 #Not required if using ping_mode=A worker.tomcatBoromir.secret=MyPass #worker.tomcatBoromir.ping_mode=A #As of mod_jk 1.2.27 #worker.tomcatBoromir.connection_pool_size=10 (1) worker.tomcatIlluin.port=8019 worker.tomcatIlluin.host=illuin worker.tomcatIlluin.type=ajp13 worker.tomcatIlluin.lbfactor=1 worker.tomcatIlluin.prepost_timeout=1 #Not required if using ping_mode=A worker.tomcatIlluin.connect_timeout=1 #Not required if using ping_mode=A worker.tomcatIlluin.secret=MyPass # Load-balancing behaviour worker.lbJboss.type=lb worker.lbJboss.balance_workers=jbossBoromir worker.lbTomcat.type=lb worker.lbTomcat.balance_workers=tomcatBoromir worker.lbOld.type=lb worker.lbOld.balance_workers=tomcatIlluin # Status worker for managing load balancer worker.status.type=status Hi. (In the hope that solving this will help improve the weather in Belgium) About your main issue : in my own experience, whenever we get the kind of error messages which you indicate, they are right. It really means that the back-end Tomcat is for some reason not responding to Apache/mod_jk within a certain limit of time. That can be because it is really down, or because it is very busy doing something else (all threads are already processing requests, or the requested webapp is busy starting up, or something like that). Or, you may be having network connectivity problems (but that would normally not be the case if both Apache and Tomcat are on the same host). But maybe the confusion below about load balancing is the root cause of the problems. I don't know if I am understanding your quoted configuration correctly, but if I do, it puzzles me a bit. You seem to have 3 separate servlet engines : on localhost, you have a jBoss and a Tomcat and on illuin, you have a Tomcat. The jBoss on localhost has an AJP Connector listening on port 8009. The corresponding worker is named jbossBoromir. The Tomcat on localhost has an AJP Connector listening on port 8019. The corresponding worker is named tomcatBoromir. The Tomcat on illuin has an AJP Connector listening on port 8019. The corresponding worker is named tomcatIlluin. Then for each one, you have an additional load balancer worker. So each load balancer worker only balances a single Tomcat/jBoss. This seems a bit counter-intuitive. Why not have worker.list=jbossBoromir,tomcatBoromir,tomcatIlluin,status directly, and take the load balancer workers out of the equation, since they each balance only 1 back-end ? Or, if your idea is really to balance all requests between all 3 back-ends, then use one single load-balancer worker, but have it balance all 3 real workers. Like : worker.list=lb,status worker.lb.balance_workers=jbossBoromir,tomcatBoromir,tomcatIlluin The point is, in my understanding, a load balancer worker only makes sense if it balances at least 2 real workers (tomcat or jboss). Otherwise it seems pretty pointless. Or is it only in order to be able to use the status worker ? What do your JkMount lines at the Apache level look like ? That may allow us to figure out what you are trying to achieve. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- David Delbecq ICT Institut Royal Météorologique Ext:557 - To unsubscribe, e-mail:
RE: download a small file from tomcat server
Albert, This is a topic for a web programming forum, not a Tomcat forum. In the meantime, just copy the file to your local machine, create an HTML page with a link to the file, and test your JS. If in tomcat, stick the file in the tomcat root, create an HTML page with a link to the file, and then hit tomcat to test your JS. -Original Message- From: albertkao [mailto:albertk...@gmail.com] Sent: Friday, February 12, 2010 8:55 AM To: users@tomcat.apache.org Subject: download a small file from tomcat server I like to download a small file (C:\dir1\data.txt) from tomcat server to my local machine which is running a Prototype javascript. How to do that? Any sample code or tutorial? -- View this message in context: http://old.nabble.com/download-a-small-file-from-tomcat-server-tp2756475 8p27564758.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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carl, On 2/12/2010 7:20 AM, Carl wrote: The 10,000 foot view: new Dell T105 and T110, Slackware 13.0 (64 bit), latest Java (64 bit) and latest Tomcat. Machines only run Tomcat and a small, special purpose Java server (which I have also moved to another machine to make certain it wasn't causing any problems.) Periodically, Tomcat just dies leaving no tracks in any log that I have been able to find. The application has run on a Slackware 12.1 (32 bit) for several years without problems (except for application bugs.) I have run memTest86 for 30 hours on the T110 with no problems reported. All of the following trials have produced the same results: One last check: have you tried a 32-bit JVM running on either a 32-bit or 64-bit OS? Your memory needs are quire modest, so a 32-bit JVM should suffice. I think you mentioned that, in the past, on lesser hardware, a 32-bit JVM was being used. The failures look a lot like the linux OOM killer (which Mark or Chris said way back at the beginning which is now 2-3 months ago.) While the Linux OOM killer /is/ possible, I agree with Chuck that it's sounding less like a memory problem. I would have bet on a hardware problem, but memtest86 seems to have ruled that out (any x86 system I've suspected of having flaky hardware has always failed on it's first round of memtest86 testing). I wonder if there's a memtest_x64 that you should be trying, instead shrug. I honestly can't think of any other reason why Tomcat would be just dying with no trace: a clean shutdown would produce logs. The Linux OOM killer would say something in the system logs (you're not doing remote syslogging, and the message is somehow getting lost, are you?). A JVM bug would likely generate an hs_pid.log file with details of the crash. I have to admit, I'm stumped. :( - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1cAcACgkQ9CaO5/Lv0PB6lgCfc2s6FpRt+LNqzgNV2KG76FiZ VeQAn3utd641tdOet+lQkG+QjpUg/txt =QLU+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: 64bit Server + JDK 1.5 (64bit) + Tomcat 5.0.28?
Hello, if we decide to upgrade our Tomcat 5.0.28 to some more reason version, should we go to 5.5.* or 6.0.24 ?? Our most important requirement is high performance, memory consumption is not so important. Thank you! -Ursprungliche Nachricht- Von: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Gesendet: Freitag, 12. Februar 2010 14:52 An: Tomcat Users List Betreff: RE: 64bit Server + JDK 1.5 (64bit) + Tomcat 5.0.28? From: Stefan Rainer [mailto:s.rai...@teamaxess.com] Subject: AW: 64bit Server + JDK 1.5 (64bit) + Tomcat 5.0.28? I would now like to optimize the thread configuration of our Tomcat There's not much point in trying to optimize an unsupported, six-year-old version of Tomcat. Your time would be better spent upgrading to a current level, which includes significant performance improvements. - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What governs a URL connection timeout?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter, On 2/12/2010 7:34 AM, Peter Crowther wrote: Chris, did you actually read the link or was that a knee-jerk response? Notably the following, taken from between the first and second boxed pieces of code on that page: The openStream() method is actually just a shortcut for openConnection().getInputStream(). ... plus the source of openStream() to prove it. So, yes, you *are* using a URLConnection internally. And... correct, you're not setting any timeouts in your code. But you want to. That page provides code further down that allows you to set such a timeout. It's possible that (the other) Chris is using a library (ep.ext, whatever that is) that hides the complexities of the connection, etc. His only recourse might be to abandon the use of that library and instead code directly to URLConnection, where he /can/ set timeouts. I'd first check the ep.ext library, though. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1cpEACgkQ9CaO5/Lv0PCsagCdENcFHvtDaZi+sJGfOsj3Ok/f kTYAoJYammldKfhOU5x/FpIFTB7oUrzQ =XoCj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat dies suddenly
I've been following this thread with interest, but haven't weighed in since I'm doing much development these days. I have to say that I'm agreeing with Chuck and Chris that it is a resource issue - especially since it doesn't appear to be a problem unless under load. Also, the OOP mentioned that it doesn't seem to occur if only the production app is being hit. It takes someone using one of the other copies first to generate the problem. So the questions occur: 1) Are you absolutely positive that there is no code that could be calling exit()? 2) Are you sharing jar files or classes between the apps? If so, place a separate copy in the WEB-INF/lib directory of each webapp, and remove them from the shared location, to insure that you're not having an issue with one app stomping on another. The combined load on a resource in a shared class could be overloading some built-in limit, and that class could be causing the fail without logging an error, or you're not catching the error to log it. 3) You have the disk space, try turning on debug level in all your logging utilities and see what the apps were last doing. Jeff *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments.
RE: Tomcat dies suddenly
You haven't said if you tried a previous java version or tomcat version (6.0.20)? -Tony Sent from my Windows® phone. -Original Message- From: Carl c...@etrak-plus.com Sent: Friday, February 12, 2010 5:22 AM To: Tomcat Users List users@tomcat.apache.org Subject: Re: Tomcat dies suddenly This problem continues to plague me. A quick recap so you don't have to search your memory or archives. The 10,000 foot view: new Dell T105 and T110, Slackware 13.0 (64 bit), latest Java (64 bit) and latest Tomcat. Machines only run Tomcat and a small, special purpose Java server (which I have also moved to another machine to make certain it wasn't causing any problems.) Periodically, Tomcat just dies leaving no tracks in any log that I have been able to find. The application has run on a Slackware 12.1 (32 bit) for several years without problems (except for application bugs.) I have run memTest86 for 30 hours on the T110 with no problems reported. More details: the Dell 105 has an AMD processor and (currently) 8 GB memory. The T110 has a Xeon 3440 processor and 4 GB memory. The current Java version is 1.6.0_18-b07. The current Tomcat version is 6.0.24. The servers are lightly loaded with less than 100 sessions active at any one time. All of the following trials have produced the same results: 1. Tried openSuse 64 bit. 2. Tried 32 bit Slackware 13. 3. Increased the memory in the T105 from 4GB to 6 GB and finally to 8 GB. 4. Have fiddled with the JAVA_OPTS settings in catalina.sh. The current settings are: JAVA_OPTS=-Xms512m -Xmx512m -XX:PermSize=384m -XX:MaxPermSize=384m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/tomcat/logs I can see the incremental GC effects in both catalina.out and VisualJVM. Note the fairly small (512MB) heap but watching VisualJVM indicates this is sufficient (when a failure occurs, VisualJVM will report the last amount of memory used and this is always well under the max in both heap and permGen.) More information about the failures: 1. They are clean kills as I can restart Tomcat immediately after failure and there is no port conflict. As I understand it, this implies the linux process was killed (I have manually killed the java process with kill -9 and had the same result that I have observed when the system fails) or Tomcat was shut down normally, e.g., using shutdown.sh (this always leaves tracks in catalina.out and I am not seeing any so I do not believe this is the case.) 2. They appear to be load related. On heavy processing days, the system might fail every 15 minutes but it could also run for up to 10 days without failure but with lighter processing. I have found a way to force a more frequent failure. We have four war's deployed (I will call them A, B, C and D.) They are all the same application but we use this process to enable access to different databases. A user accesses the correct application by https://xx.com/A or B, etc. A is used for production while the others have specific purposes. Thus, A is always used while the others are used periodically. If users start coming in on B, C and/or D, within hours the failure occurs (Tomcat shuts down bringing all of the users down, of course.) Note that the failure still does not happen immediately. 3. They do not appear to be caused by memory restrictions as 1) the old server had only 2 GB of memory and ran well, 2) I have tried adding memory to the new servers with no change in behavior and 3) the indications from top and the Slackware system monitor are that the system is not starved for memory. In fact, yesterday, running on the T105 with 8 GB of memory, top never reported over 6 GB being used (0 swap being used) yet it failed at about 4:00PM. 4. Most of the failures will occur after some amount of processing. We update the war's and restart the Tomcats each morning at 1:00AM. Most of the failures will occur toward the end of the day although heavy processing (or using multiple 'applications') may force it to happen earlier (the earliest failure has been around 1:00PM... it was the heaviest processing day ever.) It is almost as if there is a bucket somewhere that gets filled up and, when filled, causes the failure. (So there is no misunderstanding, there has never been an OOM condition reported anywhere that I can find.) Observations (or random musings): The fact that the failures occur after some amount of processing implies that the issue is related to memory usage, and, potentially, caused by a memory leak in the application. However, 1) I have never seen (from VisualJVM) any issue with either heap or permGen and the incremental GC's reported in catalina.out look pretty normal and 2) top, vmstat, system monitor, etc. are not showing any issues with memory. The failures look a lot like the linux OOM killer (which
RE: 64bit Server + JDK 1.5 (64bit) + Tomcat 5.0.28?
From: Stefan Rainer [mailto:s.rai...@teamaxess.com] Subject: AW: 64bit Server + JDK 1.5 (64bit) + Tomcat 5.0.28? if we decide to upgrade our Tomcat 5.0.28 to some more reason version, should we go to 5.5.* or 6.0.24 ?? Definitely 6.0.24 (or whatever's current when you do move up). Also use JDK 6, which is measurably faster than 1.5 in most circumstances. - 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: 64bit Server + JDK 1.5 (64bit) + Tomcat 5.0.28?
On 12/02/2010 13:51, Caldarale, Charles R wrote: From: Stefan Rainer [mailto:s.rai...@teamaxess.com] Subject: AW: 64bit Server + JDK 1.5 (64bit) + Tomcat 5.0.28? I would now like to optimize the thread configuration of our Tomcat There's not much point in trying to optimize an unsupported, six-year-old version of Tomcat. Your time would be better spent upgrading to a current level, which includes significant performance improvements. +1. Heck, just upgrading to a 1.6 JDK should give a noticeable improvement. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: What governs a URL connection timeout?
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: What governs a URL connection timeout? It's possible that (the other) Chris is using a library The OP already posted the code of interest, and it would be simple to modify it to set an appropriate timeout value, as Peter pointed out. Just replace: InputStream t_inputStream = t_url.openStream(); with URLConnection t_connection = t_url.openConnection(); t_connection.setReadTimeout(desiredValue); InputStream t_inputStrem = t_connection.getInputStream(); - 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.
Re: Tomcat dies suddenly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey,
On 2/12/2010 10:31 AM, Jeffrey Janner wrote:
Also, the OP mentioned that it doesn't seem to occur if only the
production app is being hit. It takes someone using one of the other
copies first to generate the problem. So the questions occur:
1) Are you absolutely positive that there is no code that could be
calling exit()?
One way to check this would be to launch the JVM using a script that
captures the exit code of the process:
$!/bin/sh
# Grab all these variable definitions from bin/catalina.sh
$_RUNJAVA $LOGGING_CONFIG $JAVA_OPTS $CATALINA_OPTS \
-Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS -classpath $CLASSPATH \
-Dcatalina.base=$CATALINA_BASE \
-Dcatalina.home=$CATALINA_HOME \
-Djava.io.tmpdir=$CATALINA_TMPDIR \
org.apache.catalina.startup.Bootstrap $@ start \
$CATALINA_BASE/logs/catalina.out 21
result=$?
echo JVM existed with status code=${result}
If it's 0, then the changes that this is due to a System.exit(0) call
are very high.
You could also try running under a SecurityManager, and prohibit
System.exit() calls.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkt1eKMACgkQ9CaO5/Lv0PBMIACgkZAP4UQQqVpELU2Ej4HQFOLI
7GEAn1rsUxRxvyXBrKGBYlomkaI0WN8C
=hSGU
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What governs a URL connection timeout?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 2/12/2010 10:46 AM, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: What governs a URL connection timeout? It's possible that (the other) Chris is using a library The OP already posted the code of interest Duh. That's what I get for not reading every word of the OP. Just replace: InputStream t_inputStream = t_url.openStream(); with URLConnection t_connection = t_url.openConnection(); t_connection.setReadTimeout(desiredValue); InputStream t_inputStrem = t_connection.getInputStream(); +1 Or, setConnectTimeout() which answers the OP's actual question, but wouldn't end up solving his problem. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1el4ACgkQ9CaO5/Lv0PBcZwCgs0DDTQpjlCzo7QJ+kP84Obo0 E9UAoIOk6Bm5CLCNWBb1g/jXy9p8hDZ8 =6wCb -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
performance problems with Tomcat 6 and JSF 1.2
Hi, I noticed serious performance problems with JSF 1.2 and Tomcat which seems to be caused by Tomcat. One major performace problem is bug https://issues.apache.org/bugzilla/show_bug.cgi?id=48600 Setting metadata-complete=true in web.xml improved the speed significantly But there seems to be still another problem in Tomcat. I deployed the same apps to Jetty. Average results of 500 calls of a simple jsf page (jsp) with 1000 h:output tags: JSF 1.1: Tomcat 6.0.24: 26ms Jetty 7.0.1: 35ms JSF 1.2: Tomcat 6.0.24: 72ms Jetty 7.0.1: 41ms Any ideas regarding the bad performance of Tomcat with JSF 1.2? The simple page does not contain any EL expressions, just 1000 simple tags: h:outputText value=1 style=z-index:29202;/. Michael
RE: download a small file from tomcat server
Joseph Morgan-2 wrote: Albert, This is a topic for a web programming forum, not a Tomcat forum. In the meantime, just copy the file to your local machine, create an HTML page with a link to the file, and test your JS. If in tomcat, stick the file in the tomcat root, create an HTML page with a link to the file, and then hit tomcat to test your JS. -Original Message- From: albertkao [mailto:albertk...@gmail.com] Sent: Friday, February 12, 2010 8:55 AM To: users@tomcat.apache.org Subject: download a small file from tomcat server I like to download a small file (C:\dir1\data.txt) from tomcat server to my local machine which is running a Prototype javascript. How to do that? Any sample code or tutorial? -- View this message in context: http://old.nabble.com/download-a-small-file-from-tomcat-server-tp2756475 8p27564758.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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org What is the proper forum to ask the question? The goal is to refresh a JSP web page on a web browser when the Apache Derby DB database on the server is changed. The rate of database change is 1-10 times per hour. The record size is about 1000 bytes. The user use the browser to modify the data and write back to the Apache Derby DB database. The web server is tomcat. I am thinking of comet programming - pushing data from the server to client when the Derby DB is changed. Is that a good idea? How to do that with javascript or java? Any sample code or tutorial? -- View this message in context: http://old.nabble.com/download-a-small-file-from-tomcat-server-tp27564758p27565937.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: Tomcat dies suddenly
Chris, Thanks for your response. I'll try to find a memtest for 64 bit. On the 32 bit topic. I have run successfully for several years on a Slackware 12.1 32 bit system (Java 1.5 something, Tomcat 5.5.25.) When I brought up Slackware 13.0 32 bit, and the latest Tomcat and Java (32 bit, of course), it suffered from the same problem which surprised me. Also, one of the reasons for going to 64 bit was that we have had problems when some people were running B, C and D (permGen, very clear) so I was trying to get a little extra memory. No, we are not doing remote logging (the servers are 10' away from me.) Me stumped also... has always been so simple to set up a Tomcat server. Do I gain anything by trying Glassfish? Thanks, Carl - Original Message - From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 10:13 AM Subject: Re: Tomcat dies suddenly -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carl, On 2/12/2010 7:20 AM, Carl wrote: The 10,000 foot view: new Dell T105 and T110, Slackware 13.0 (64 bit), latest Java (64 bit) and latest Tomcat. Machines only run Tomcat and a small, special purpose Java server (which I have also moved to another machine to make certain it wasn't causing any problems.) Periodically, Tomcat just dies leaving no tracks in any log that I have been able to find. The application has run on a Slackware 12.1 (32 bit) for several years without problems (except for application bugs.) I have run memTest86 for 30 hours on the T110 with no problems reported. All of the following trials have produced the same results: One last check: have you tried a 32-bit JVM running on either a 32-bit or 64-bit OS? Your memory needs are quire modest, so a 32-bit JVM should suffice. I think you mentioned that, in the past, on lesser hardware, a 32-bit JVM was being used. The failures look a lot like the linux OOM killer (which Mark or Chris said way back at the beginning which is now 2-3 months ago.) While the Linux OOM killer /is/ possible, I agree with Chuck that it's sounding less like a memory problem. I would have bet on a hardware problem, but memtest86 seems to have ruled that out (any x86 system I've suspected of having flaky hardware has always failed on it's first round of memtest86 testing). I wonder if there's a memtest_x64 that you should be trying, instead shrug. I honestly can't think of any other reason why Tomcat would be just dying with no trace: a clean shutdown would produce logs. The Linux OOM killer would say something in the system logs (you're not doing remote syslogging, and the message is somehow getting lost, are you?). A JVM bug would likely generate an hs_pid.log file with details of the crash. I have to admit, I'm stumped. :( - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1cAcACgkQ9CaO5/Lv0PB6lgCfc2s6FpRt+LNqzgNV2KG76FiZ VeQAn3utd641tdOet+lQkG+QjpUg/txt =QLU+ -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
Re: download a small file from tomcat server
On 12/02/2010 16:21, albertkao wrote: Joseph Morgan-2 wrote: Albert, This is a topic for a web programming forum, not a Tomcat forum. In the meantime, just copy the file to your local machine, create an HTML page with a link to the file, and test your JS. If in tomcat, stick the file in the tomcat root, create an HTML page with a link to the file, and then hit tomcat to test your JS. -Original Message- From: albertkao [mailto:albertk...@gmail.com] Sent: Friday, February 12, 2010 8:55 AM To: users@tomcat.apache.org Subject: download a small file from tomcat server I like to download a small file (C:\dir1\data.txt) from tomcat server to my local machine which is running a Prototype javascript. How to do that? Any sample code or tutorial? -- View this message in context: http://old.nabble.com/download-a-small-file-from-tomcat-server-tp2756475 8p27564758.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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org What is the proper forum to ask the question? This list is generally for people having problems installing, configuring or operating the Tomcat application server. The goal is to refresh a JSP web page on a web browser when the Apache Derby DB database on the server is changed. The rate of database change is 1-10 times per hour. The record size is about 1000 bytes. The user use the browser to modify the data and write back to the Apache Derby DB database. The web server is tomcat. I am thinking of comet programming - pushing data from the server to client when the Derby DB is changed. Is that a good idea? How to do that with javascript or java? Any sample code or tutorial? You're probably looking for a tutorial website or forum. This list is usually best at providing assistance when someone asks a specific question, (where we're able to provide specific answers), rather than showing you how to write an application. p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
Jeffrey, Thanks for taking the time to give this some thought. 1. There is no place in the code that we intentionally put an exit(). I have grepped for exit() and found nothing. The system stops in a different place every time... the last entry in catalina.out has never been the same (over 15-20 failures.) 2. No, we do not share jars or classes... our thought was this was a potential for screwups and not really gaining anything. 3. Good idea... I will try this. Thanks, Carl - Original Message - From: Jeffrey Janner jeffrey.jan...@polydyne.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 10:31 AM Subject: RE: Tomcat dies suddenly I've been following this thread with interest, but haven't weighed in since I'm doing much development these days. I have to say that I'm agreeing with Chuck and Chris that it is a resource issue - especially since it doesn't appear to be a problem unless under load. Also, the OOP mentioned that it doesn't seem to occur if only the production app is being hit. It takes someone using one of the other copies first to generate the problem. So the questions occur: 1) Are you absolutely positive that there is no code that could be calling exit()? 2) Are you sharing jar files or classes between the apps? If so, place a separate copy in the WEB-INF/lib directory of each webapp, and remove them from the shared location, to insure that you're not having an issue with one app stomping on another. The combined load on a resource in a shared class could be overloading some built-in limit, and that class could be causing the fail without logging an error, or you're not catching the error to log it. 3) You have the disk space, try turning on debug level in all your logging utilities and see what the apps were last doing. Jeff *** NOTICE * This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
On 12 February 2010 16:43, Carl c...@etrak-plus.com wrote: 1. There is no place in the code that we intentionally put an exit(). I have grepped for exit() and found nothing. The system stops in a different place every time... the last entry in catalina.out has never been the same (over 15-20 failures.) I'm wondering about a concurrency issue, given that the failure occurs more frequently under load but can occur at other times. But it's difficult to think of one that would cause a silent crash like this, unless you're using a library somewhere that makes use of the crash and burn school of error handling! ... actually, that's a thought. There *is* a way of you distinguishing the VM exiting in an orderly fashion, quitting, or being terminated, and that's to add a tiny webapp that just registers a shutdown hook (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Runtime.html#addShutdownHook%28java.lang.Thread%29). If you're willing to add that debug code, then you could log a message (or simply touch a file). If there's no message/file, the VM is shutting down due to an error or someone's calling halt (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Runtime.html#halt%28int%29). As another small piece of debugging, it would be very interesting to capture the exit status of the JVM. How are you starting it, and is there any chance of inspecting the code on exit? A non-zero exit code, in particular, would be interesting. As a third, rather larger, piece of debugging, you could consider running Tomcat under a security manager that allowed all operations except exit. This may be tough to get right, especially on a production server, but it would definitely tell you whether there were any Java calls to Runtime.exit() or Runtime.halt(). Finally, is there any native code in any part of your application? This is, of course, outside of any of the JVM handlers; a failure of native code can (and occasionally does!) cause mayhem. None of this is a solution, I'm afraid. It's all just more debugging and gathering more information. But the problem is sufficiently unusual that I think you're going to have to keep on debugging it :-(. - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
Is it possible to run this server with a basic tomcat application under load to rule out the application causing the crash? On Fri, Feb 12, 2010 at 4:20 AM, Carl c...@etrak-plus.com wrote: This problem continues to plague me. A quick recap so you don't have to search your memory or archives. The 10,000 foot view: new Dell T105 and T110, Slackware 13.0 (64 bit), latest Java (64 bit) and latest Tomcat. Machines only run Tomcat and a small, special purpose Java server (which I have also moved to another machine to make certain it wasn't causing any problems.) Periodically, Tomcat just dies leaving no tracks in any log that I have been able to find. The application has run on a Slackware 12.1 (32 bit) for several years without problems (except for application bugs.) I have run memTest86 for 30 hours on the T110 with no problems reported. More details: the Dell 105 has an AMD processor and (currently) 8 GB memory. The T110 has a Xeon 3440 processor and 4 GB memory. The current Java version is 1.6.0_18-b07. The current Tomcat version is 6.0.24. The servers are lightly loaded with less than 100 sessions active at any one time. All of the following trials have produced the same results: 1. Tried openSuse 64 bit. 2. Tried 32 bit Slackware 13. 3. Increased the memory in the T105 from 4GB to 6 GB and finally to 8 GB. 4. Have fiddled with the JAVA_OPTS settings in catalina.sh. The current settings are: JAVA_OPTS=-Xms512m -Xmx512m -XX:PermSize=384m -XX:MaxPermSize=384m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/tomcat/logs I can see the incremental GC effects in both catalina.out and VisualJVM. Note the fairly small (512MB) heap but watching VisualJVM indicates this is sufficient (when a failure occurs, VisualJVM will report the last amount of memory used and this is always well under the max in both heap and permGen.) More information about the failures: 1. They are clean kills as I can restart Tomcat immediately after failure and there is no port conflict. As I understand it, this implies the linux process was killed (I have manually killed the java process with kill -9 and had the same result that I have observed when the system fails) or Tomcat was shut down normally, e.g., using shutdown.sh (this always leaves tracks in catalina.out and I am not seeing any so I do not believe this is the case.) 2. They appear to be load related. On heavy processing days, the system might fail every 15 minutes but it could also run for up to 10 days without failure but with lighter processing. I have found a way to force a more frequent failure. We have four war's deployed (I will call them A, B, C and D.) They are all the same application but we use this process to enable access to different databases. A user accesses the correct application by https://xx.com/A or B, etc. A is used for production while the others have specific purposes. Thus, A is always used while the others are used periodically. If users start coming in on B, C and/or D, within hours the failure occurs (Tomcat shuts down bringing all of the users down, of course.) Note that the failure still does not happen immediately. 3. They do not appear to be caused by memory restrictions as 1) the old server had only 2 GB of memory and ran well, 2) I have tried adding memory to the new servers with no change in behavior and 3) the indications from top and the Slackware system monitor are that the system is not starved for memory. In fact, yesterday, running on the T105 with 8 GB of memory, top never reported over 6 GB being used (0 swap being used) yet it failed at about 4:00PM. 4. Most of the failures will occur after some amount of processing. We update the war's and restart the Tomcats each morning at 1:00AM. Most of the failures will occur toward the end of the day although heavy processing (or using multiple 'applications') may force it to happen earlier (the earliest failure has been around 1:00PM... it was the heaviest processing day ever.) It is almost as if there is a bucket somewhere that gets filled up and, when filled, causes the failure. (So there is no misunderstanding, there has never been an OOM condition reported anywhere that I can find.) Observations (or random musings): The fact that the failures occur after some amount of processing implies that the issue is related to memory usage, and, potentially, caused by a memory leak in the application. However, 1) I have never seen (from VisualJVM) any issue with either heap or permGen and the incremental GC's reported in catalina.out look pretty normal and 2) top, vmstat, system monitor, etc. are not showing any issues with memory. The failures look a lot like the linux OOM killer (which Mark or Chris said way back at the beginning which is now 2-3 months ago.) Does anyone have
RE: download a small file from tomcat server
Go to the sun forums, sign up there, and then proceed to the correct area and ask your questions there. What you are asking is all very primitive programming, and many there will be able to give you answers. As a friendly hint, some out there are very abrasive towards these kinds of questions, as just about any reasonable search on JSP, DB, and server push (comet) will wield about 100 tutorials. Joe -Original Message- From: albertkao [mailto:albertk...@gmail.com] Sent: Friday, February 12, 2010 10:21 AM To: users@tomcat.apache.org Subject: RE: download a small file from tomcat server Joseph Morgan-2 wrote: Albert, This is a topic for a web programming forum, not a Tomcat forum. In the meantime, just copy the file to your local machine, create an HTML page with a link to the file, and test your JS. If in tomcat, stick the file in the tomcat root, create an HTML page with a link to the file, and then hit tomcat to test your JS. -Original Message- From: albertkao [mailto:albertk...@gmail.com] Sent: Friday, February 12, 2010 8:55 AM To: users@tomcat.apache.org Subject: download a small file from tomcat server I like to download a small file (C:\dir1\data.txt) from tomcat server to my local machine which is running a Prototype javascript. How to do that? Any sample code or tutorial? -- View this message in context: http://old.nabble.com/download-a-small-file-from-tomcat-server-tp2756475 8p27564758.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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org What is the proper forum to ask the question? The goal is to refresh a JSP web page on a web browser when the Apache Derby DB database on the server is changed. The rate of database change is 1-10 times per hour. The record size is about 1000 bytes. The user use the browser to modify the data and write back to the Apache Derby DB database. The web server is tomcat. I am thinking of comet programming - pushing data from the server to client when the Derby DB is changed. Is that a good idea? How to do that with javascript or java? Any sample code or tutorial? -- View this message in context: http://old.nabble.com/download-a-small-file-from-tomcat-server-tp2756475 8p27565937.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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
2010/2/12 Carl c...@etrak-plus.com: More details: the Dell 105 has an AMD processor and (currently) 8 GB memory. The T110 has a Xeon 3440 processor and 4 GB memory. The current Java version is 1.6.0_18-b07. The current Tomcat version is 6.0.24. Actually, 6.0.24 version *will* exit silently if it is terminated by a signal. To reproduce (on Windows): 1. Run Tomcat in a console window. 2. Press Ctrl+C 3. Tomcat shutdowns in several seconds, cleanly, but silently. That is because in 6.0.24 a VM shutdown hook was added that cleanly terminates logging subsystem (flushing all cached messages). The VM starts all shutdown hook threads at the same time and they run in parallel. Thus if Tomcat is being stopped through a hook, the logging subsystem has a chance to be already shut down at that time. I think that the same silent shutdown will occur if calling System.exit(), by the same reason. I do not know, what will happen if running Tomcat with jsvc on a Unix. (IIRC, jsvc calls the stop method in Bootstrap/Catalina, so Tomcat shuts down not through a hook and all messages should be present). The above is specific to 6.0.24. In 6.0.20 logs are forcibly flushed after each message is written, and log files are never explicitly closed. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Socket Error in tomcat, white screen in browser
I am having a problem a strange problem in my Tomcat application. Before I
get started then here is my system information:
- Eclipse 3.4.2
- apache-tomcat-6.0.20
It used to work, but now it doesn't. The problem is when I try to view my
tomcat pages in my browser then it goes straight to a white screen. Tomcat
appears to be starting, but it lists some problems before starting. Here is
what my console says:
Feb 12, 2010 10:47:44 AM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path: C:\Program
Files\Java\jre6\bin;.;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:/Program
Files/Java/jre6/bin/client;C:/Program Files/Java/jre6/bin;C:\Program
Files\Common Files\Microsoft Shared\Windows
Live;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\MinGW\bin;C:\Program
Files\QuickTime\QTSystem\C:\Program Files\QuickTime\QTSystem\;C:\Program
Files\Java\jdk1.6.0_17\bin;C:\Program Files\QuickTime\QTSystem\;C:\Program
Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files\Nmap
Feb 12, 2010 10:47:44 AM org.apache.coyote.http11.Http11Protocol init
SEVERE: Error initializing endpoint
java.net.SocketException: Unrecognized Windows Sockets error: 0: JVM_Bind
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(Unknown Source)
at java.net.ServerSocket.bind(Unknown Source)
at java.net.ServerSocket.init(Unknown Source)
at java.net.ServerSocket.init(Unknown Source)
at
org.apache.tomcat.util.net.DefaultServerSocketFactory.createSocket(DefaultServerSocketFactory.java:50)
at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:503)
at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:176)
at
org.apache.catalina.connector.Connector.initialize(Connector.java:1058)
at
org.apache.catalina.core.StandardService.initialize(StandardService.java:677)
at
org.apache.catalina.core.StandardServer.initialize(StandardServer.java:795)
at org.apache.catalina.startup.Catalina.load(Catalina.java:535)
at org.apache.catalina.startup.Catalina.load(Catalina.java:555)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:260)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:412)
Feb 12, 2010 10:47:44 AM org.apache.catalina.startup.Catalina load
SEVERE: Catalina.start
LifecycleException: Protocol handler initialization failed:
java.net.SocketException: Unrecognized Windows Sockets error: 0: JVM_Bind
at
org.apache.catalina.connector.Connector.initialize(Connector.java:1060)
at
org.apache.catalina.core.StandardService.initialize(StandardService.java:677)
at
org.apache.catalina.core.StandardServer.initialize(StandardServer.java:795)
at org.apache.catalina.startup.Catalina.load(Catalina.java:535)
at org.apache.catalina.startup.Catalina.load(Catalina.java:555)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:260)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:412)
Feb 12, 2010 10:47:44 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 503 ms
Feb 12, 2010 10:47:44 AM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Feb 12, 2010 10:47:44 AM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.20
Feb 12, 2010 10:47:45 AM org.apache.catalina.loader.WebappClassLoader
validateJarFile
INFO:
validateJarFile(C:\Users\Steven\EclipseWorkSpaces\TomcatWorkspace\workspace\ps1-semiller\WEB-INF\lib\servlet-api.jar)
- jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class:
javax/servlet/Servlet.class
Feb 12, 2010 10:47:45 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive standard-examples.war
Feb 12, 2010 10:47:45 AM org.apache.catalina.core.ApplicationContext log
INFO: ContextListener: contextInitialized()
Feb 12, 2010 10:47:45 AM org.apache.catalina.core.ApplicationContext log
INFO: SessionListener: contextInitialized()
Feb 12, 2010 10:47:45 AM org.apache.catalina.core.ApplicationContext log
INFO: ContextListener: attributeAdded('org.apache.catalina.Registry',
RE: Tomcat dies suddenly
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Subject: Re: Tomcat dies suddenly Actually, 6.0.24 version *will* exit silently if it is terminated by a signal. To reproduce (on Windows): 1. Run Tomcat in a console window. 2. Press Ctrl+C 3. Tomcat shutdowns in several seconds, cleanly, but silently. Not for me; I get the following in catalina.2010-02-12.log after entering CTRL-C: Feb 12, 2010 12:53:42 PM org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 This is Tomcat 6.0.24, JDK 1.6.0_14, Windows XP Pro 32-bit. - 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: Socket Error in tomcat, white screen in browser
From: millerKiller [mailto:smille8...@hotmail.com] Subject: Socket Error in tomcat, white screen in browser I don't understand, my tomcat was working last week just fine and now it is acting weird? Is there anyone that can help me figure it out? Welcome to the Wacky World of Windows. 1) Use netstat -ano to make sure the ports you've configured for Tomcat are not already in use (by VMware, for example). 2) Check your Windows firewall to make sure those ports are available. 3) Reboot (early and often). - 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: digest algorithm in BASIC auth
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Antonio, On 2/12/2010 6:12 AM, banto wrote: my tomcat conf has basic auth and i have a the following in web.xml login-config auth-methodBASIC/auth-method realm-nameThe HTML Application/realm-name /login-config That is HTTP BASIC AUTH. now i´m seeing that the password during the auth is digested and has value. Authorization: Basic YW50b25pbzpwYXNzd29yZA== My problem is that i cannot understand where it comes from... That's base64(username + ':' + password). Your username is 'antonio' and your password is 'password' in this case. I´m trying all the combination, i mean i´m digesting user:realm:password with all of the algorithms but i cannot get that value. You are confusing the above with HTTP DIGEST AUTH, which requires md5(user + ':' + realm + ':' + password) Along with Konstantin's reference, you should also read this one: http://en.wikipedia.org/wiki/Http_digest_authentication - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1pxoACgkQ9CaO5/Lv0PCo1gCgoHNO/WVMn7BlX48B1VlavGte MfYAn3AjZY6XyRHFIg2xBCFL7JEn+k5k =w9Gu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Socket Error in tomcat, white screen in browser
Thanks for the quick response Chuck. I might need a little guidance on some of the things you mentioned. I believe I have Tomcat configured to go through port 80 and it is going through my machine locally. Where do I check to make sure? I checked windows firewall and it is allowing eclipse to go through the firewall. If port 80 shows up on netstat, then is this a problem? I though multiple things could use port 80. (i.e. assign dynamically) thanks, millerkiller -- View this message in context: http://old.nabble.com/Socket-Error-in-tomcat%2C-white-screen-in-browser-tp27567722p27568110.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: Socket Error in tomcat, white screen in browser
From: millerKiller [mailto:smille8...@hotmail.com] Subject: RE: Socket Error in tomcat, white screen in browser I believe I have Tomcat configured to go through port 80 That configuration is in conf/server.xml; be aware that Eclipse often uses its own Tomcat config, not the one you think you're using. If port 80 shows up on netstat, then is this a problem? Yes. I though multiple things could use port 80. Only one process at a time may use a given ip:port combination. - 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: Re-deploying a war file - RESOLVED
-Original Message- After reading the Tomcat 6.0 User Guide, Section 4, Deployer -Deploying on a running war Tomcat I expected to be able to just drop the updated war file into the web apps folder, overwriting the old war file of the same name and it would automatically replace the previously exploded war with the new. The document says, 'If the Host autoDeploy attribute is true, the Host will attempt to deploy and update web applications dynamically, as needed, for example if a new .WAR is dropped into the appBase. For this to work, the Host needs to have background processing enabled which is the default configuration'. I could not get this to happen. The new war would not re-deploy while Tomcat was running and would not re-deploy after restarting Tomcat. I needed to set the Host attribute autoDeploy=true in the server.xml Setting the Context attribute reloadable=true also works but is Not recommended for use on deployed production applications Context reloadable=true antiJARLocking=true unpackWARs=true Realm appName=xxWeb className=org.apache.catalina.realm.JAASRealm debug=99 userClassNames=Webxx.LoginPrincipal allRolesMode=strictAuthOnly / /Context Tomcat Configuration Reference, Context section link to Automatic Application Deployment where I read the following, 'If you redeploy an updated WAR file, be sure to delete the expanded directory when restarting Tomcat, so that the updated WAR file will be re-expanded (note that the auto deployer, if enabled, will automatically expand the updated WAR file once the previously expanded directory is removed).' This also works Joe - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
Tony, Thanks for your response. Way back (several months ago), I did start with an older version of Tomcat. When it showed the failures, I moved forward to the current version with a step in between. I did not try to go back to 5.5 or Java 1.5 (and I think that would be counter productive.) Thanks, Carl - Original Message - From: Anthony J. Biacco abia...@formatdynamics.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 10:36 AM Subject: RE: Tomcat dies suddenly You haven't said if you tried a previous java version or tomcat version (6.0.20)? -Tony Sent from my Windows® phone. -Original Message- From: Carl c...@etrak-plus.com Sent: Friday, February 12, 2010 5:22 AM To: Tomcat Users List users@tomcat.apache.org Subject: Re: Tomcat dies suddenly This problem continues to plague me. A quick recap so you don't have to search your memory or archives. The 10,000 foot view: new Dell T105 and T110, Slackware 13.0 (64 bit), latest Java (64 bit) and latest Tomcat. Machines only run Tomcat and a small, special purpose Java server (which I have also moved to another machine to make certain it wasn't causing any problems.) Periodically, Tomcat just dies leaving no tracks in any log that I have been able to find. The application has run on a Slackware 12.1 (32 bit) for several years without problems (except for application bugs.) I have run memTest86 for 30 hours on the T110 with no problems reported. More details: the Dell 105 has an AMD processor and (currently) 8 GB memory. The T110 has a Xeon 3440 processor and 4 GB memory. The current Java version is 1.6.0_18-b07. The current Tomcat version is 6.0.24. The servers are lightly loaded with less than 100 sessions active at any one time. All of the following trials have produced the same results: 1. Tried openSuse 64 bit. 2. Tried 32 bit Slackware 13. 3. Increased the memory in the T105 from 4GB to 6 GB and finally to 8 GB. 4. Have fiddled with the JAVA_OPTS settings in catalina.sh. The current settings are: JAVA_OPTS=-Xms512m -Xmx512m -XX:PermSize=384m -XX:MaxPermSize=384m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/tomcat/logs I can see the incremental GC effects in both catalina.out and VisualJVM. Note the fairly small (512MB) heap but watching VisualJVM indicates this is sufficient (when a failure occurs, VisualJVM will report the last amount of memory used and this is always well under the max in both heap and permGen.) More information about the failures: 1. They are clean kills as I can restart Tomcat immediately after failure and there is no port conflict. As I understand it, this implies the linux process was killed (I have manually killed the java process with kill -9 and had the same result that I have observed when the system fails) or Tomcat was shut down normally, e.g., using shutdown.sh (this always leaves tracks in catalina.out and I am not seeing any so I do not believe this is the case.) 2. They appear to be load related. On heavy processing days, the system might fail every 15 minutes but it could also run for up to 10 days without failure but with lighter processing. I have found a way to force a more frequent failure. We have four war's deployed (I will call them A, B, C and D.) They are all the same application but we use this process to enable access to different databases. A user accesses the correct application by https://xx.com/A or B, etc. A is used for production while the others have specific purposes. Thus, A is always used while the others are used periodically. If users start coming in on B, C and/or D, within hours the failure occurs (Tomcat shuts down bringing all of the users down, of course.) Note that the failure still does not happen immediately. 3. They do not appear to be caused by memory restrictions as 1) the old server had only 2 GB of memory and ran well, 2) I have tried adding memory to the new servers with no change in behavior and 3) the indications from top and the Slackware system monitor are that the system is not starved for memory. In fact, yesterday, running on the T105 with 8 GB of memory, top never reported over 6 GB being used (0 swap being used) yet it failed at about 4:00PM. 4. Most of the failures will occur after some amount of processing. We update the war's and restart the Tomcats each morning at 1:00AM. Most of the failures will occur toward the end of the day although heavy processing (or using multiple 'applications') may force it to happen earlier (the earliest failure has been around 1:00PM... it was the heaviest processing day ever.) It is almost as if there is a bucket somewhere that gets filled up and, when filled, causes the failure. (So there is no misunderstanding, there has never been an OOM condition reported anywhere that I can find.) Observations (or random musings): The
Re: Tomcat dies suddenly
Chris,
Thank you... I would never have thought about this script. I'll fire that
baby up tonight.
Thanks,
Carl
- Original Message -
From: Christopher Schultz ch...@christopherschultz.net
To: Tomcat Users List users@tomcat.apache.org
Sent: Friday, February 12, 2010 10:49 AM
Subject: Re: Tomcat dies suddenly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey,
On 2/12/2010 10:31 AM, Jeffrey Janner wrote:
Also, the OP mentioned that it doesn't seem to occur if only the
production app is being hit. It takes someone using one of the other
copies first to generate the problem. So the questions occur:
1) Are you absolutely positive that there is no code that could be
calling exit()?
One way to check this would be to launch the JVM using a script that
captures the exit code of the process:
$!/bin/sh
# Grab all these variable definitions from bin/catalina.sh
$_RUNJAVA $LOGGING_CONFIG $JAVA_OPTS $CATALINA_OPTS \
-Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS -classpath $CLASSPATH \
-Dcatalina.base=$CATALINA_BASE \
-Dcatalina.home=$CATALINA_HOME \
-Djava.io.tmpdir=$CATALINA_TMPDIR \
org.apache.catalina.startup.Bootstrap $@ start \
$CATALINA_BASE/logs/catalina.out 21
result=$?
echo JVM existed with status code=${result}
If it's 0, then the changes that this is due to a System.exit(0) call
are very high.
You could also try running under a SecurityManager, and prohibit
System.exit() calls.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkt1eKMACgkQ9CaO5/Lv0PBMIACgkZAP4UQQqVpELU2Ej4HQFOLI
7GEAn1rsUxRxvyXBrKGBYlomkaI0WN8C
=hSGU
-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
RE: Socket Error in tomcat, white screen in browser
Here is my port information in conf/server.xml: Server port=8005 shutdown=SHUTDOWN Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / I pull up netstat -ano Here is the only thing that relates to these port numbers: Local Address Foreign Address - 127.0.0.1:8005 0.0.0.0.0 So it appears that nothing is using the same port, any other ideas? (Also, what is the correct way to respond in this forum, should I post message or send an email to you?) -- View this message in context: http://old.nabble.com/Socket-Error-in-tomcat%2C-white-screen-in-browser-tp27567722p27568387.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: Tomcat dies suddenly
Peter, Great ideas (did you see Chris's response with a way of testing the exit code?) Of course I am willing to add some debug code (I'll do almost anything at this point)... I will look at the links you provided and try it out. I've contented right along that the major issue is that the failure leaves no tracks... I'm hopeful the 'debug' code you have suggested will allow me to start to understand the underlying cause. I will leave the security manager to last as I don't know that stuff very well. There is no native code in the application (used to do a lot of work in C and I am familiar with mayhem of buffer overruns, pointer screwups, etc.) Thanks, Carl - Original Message - From: Peter Crowther peter.crowt...@melandra.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 12:05 PM Subject: Re: Tomcat dies suddenly On 12 February 2010 16:43, Carl c...@etrak-plus.com wrote: 1. There is no place in the code that we intentionally put an exit(). I have grepped for exit() and found nothing. The system stops in a different place every time... the last entry in catalina.out has never been the same (over 15-20 failures.) I'm wondering about a concurrency issue, given that the failure occurs more frequently under load but can occur at other times. But it's difficult to think of one that would cause a silent crash like this, unless you're using a library somewhere that makes use of the crash and burn school of error handling! ... actually, that's a thought. There *is* a way of you distinguishing the VM exiting in an orderly fashion, quitting, or being terminated, and that's to add a tiny webapp that just registers a shutdown hook (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Runtime.html#addShutdownHook%28java.lang.Thread%29). If you're willing to add that debug code, then you could log a message (or simply touch a file). If there's no message/file, the VM is shutting down due to an error or someone's calling halt (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Runtime.html#halt%28int%29). As another small piece of debugging, it would be very interesting to capture the exit status of the JVM. How are you starting it, and is there any chance of inspecting the code on exit? A non-zero exit code, in particular, would be interesting. As a third, rather larger, piece of debugging, you could consider running Tomcat under a security manager that allowed all operations except exit. This may be tough to get right, especially on a production server, but it would definitely tell you whether there were any Java calls to Runtime.exit() or Runtime.halt(). Finally, is there any native code in any part of your application? This is, of course, outside of any of the JVM handlers; a failure of native code can (and occasionally does!) cause mayhem. None of this is a solution, I'm afraid. It's all just more debugging and gathering more information. But the problem is sufficiently unusual that I think you're going to have to keep on debugging it :-(. - Peter - 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: Tomcat dies suddenly
Tony, I tried stressing it with JMeter and came up no results. I could push it hard enough to force an OOM but it performed/failed as expected leaving tracks all over the place. The stressing was not very sophisticated (just a couple of the production jsp's) but, like I said, it didn't show anything (I was really testing to see if the problem was in GC... it wasn't.) Might rig up a more comprehensive test... will see after I try Chris and Peter's ideas. Thanks, Carl - Original Message - From: anthonyvie...@gmail.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 12:07 PM Subject: Re: Tomcat dies suddenly Is it possible to run this server with a basic tomcat application under load to rule out the application causing the crash? On Fri, Feb 12, 2010 at 4:20 AM, Carl c...@etrak-plus.com wrote: This problem continues to plague me. A quick recap so you don't have to search your memory or archives. The 10,000 foot view: new Dell T105 and T110, Slackware 13.0 (64 bit), latest Java (64 bit) and latest Tomcat. Machines only run Tomcat and a small, special purpose Java server (which I have also moved to another machine to make certain it wasn't causing any problems.) Periodically, Tomcat just dies leaving no tracks in any log that I have been able to find. The application has run on a Slackware 12.1 (32 bit) for several years without problems (except for application bugs.) I have run memTest86 for 30 hours on the T110 with no problems reported. More details: the Dell 105 has an AMD processor and (currently) 8 GB memory. The T110 has a Xeon 3440 processor and 4 GB memory. The current Java version is 1.6.0_18-b07. The current Tomcat version is 6.0.24. The servers are lightly loaded with less than 100 sessions active at any one time. All of the following trials have produced the same results: 1. Tried openSuse 64 bit. 2. Tried 32 bit Slackware 13. 3. Increased the memory in the T105 from 4GB to 6 GB and finally to 8 GB. 4. Have fiddled with the JAVA_OPTS settings in catalina.sh. The current settings are: JAVA_OPTS=-Xms512m -Xmx512m -XX:PermSize=384m -XX:MaxPermSize=384m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/tomcat/logs I can see the incremental GC effects in both catalina.out and VisualJVM. Note the fairly small (512MB) heap but watching VisualJVM indicates this is sufficient (when a failure occurs, VisualJVM will report the last amount of memory used and this is always well under the max in both heap and permGen.) More information about the failures: 1. They are clean kills as I can restart Tomcat immediately after failure and there is no port conflict. As I understand it, this implies the linux process was killed (I have manually killed the java process with kill -9 and had the same result that I have observed when the system fails) or Tomcat was shut down normally, e.g., using shutdown.sh (this always leaves tracks in catalina.out and I am not seeing any so I do not believe this is the case.) 2. They appear to be load related. On heavy processing days, the system might fail every 15 minutes but it could also run for up to 10 days without failure but with lighter processing. I have found a way to force a more frequent failure. We have four war's deployed (I will call them A, B, C and D.) They are all the same application but we use this process to enable access to different databases. A user accesses the correct application by https://xx.com/A or B, etc. A is used for production while the others have specific purposes. Thus, A is always used while the others are used periodically. If users start coming in on B, C and/or D, within hours the failure occurs (Tomcat shuts down bringing all of the users down, of course.) Note that the failure still does not happen immediately. 3. They do not appear to be caused by memory restrictions as 1) the old server had only 2 GB of memory and ran well, 2) I have tried adding memory to the new servers with no change in behavior and 3) the indications from top and the Slackware system monitor are that the system is not starved for memory. In fact, yesterday, running on the T105 with 8 GB of memory, top never reported over 6 GB being used (0 swap being used) yet it failed at about 4:00PM. 4. Most of the failures will occur after some amount of processing. We update the war's and restart the Tomcats each morning at 1:00AM. Most of the failures will occur toward the end of the day although heavy processing (or using multiple 'applications') may force it to happen earlier (the earliest failure has been around 1:00PM... it was the heaviest processing day ever.) It is almost as if there is a bucket somewhere that gets filled up and, when filled, causes the failure. (So there is no misunderstanding, there has never been an OOM condition
tomcat response chunk size
Hi, I have an old client that does not understand the Transfer-Encoding: chunked. My tomcat response is chunked with hex 2000 (8K and a little bit less via AJP: 1FF8). Is there a way to configure Tomcat's chunk size to e.g 100K or another question where or why is it set to 8K? Interestingly, in Tomcat4 there was an attribute allowChunking=false. Many thanks, Fred -- View this message in context: http://old.nabble.com/tomcat-response-chunk-size-tp27568493p27568493.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: Tomcat dies suddenly
Carl wrote: .. a lot of messages, and I have not yet read all of them, but I sympathise with the predicament. I am very far from any kind of Java expertise, so just something that I vaguely seem to remember, although it may be from a very long time ago, not applicable, already mentioned by someone, and maybe not relevant at all.. I thus vaguely seem to remember that there existed some option to the JVM to provide a last resort amount of memory, only used if the JVM really ran out of memory, for the purpose of allowing at least some last-ditch desperate action to take place (like logging the catastrophe maybe). I don't remember how it's called or how it works, but maybe it will raise something in some expert's memory. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Socket Error in tomcat, white screen in browser
From: millerKiller [mailto:smille8...@hotmail.com] Subject: RE: Socket Error in tomcat, white screen in browser Here is my port information in conf/server.xml: Server port=8005 shutdown=SHUTDOWN Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / So there are three ports configured for this Tomcat: 8005, 80, and 8009. I pull up netstat -ano Here is the only thing that relates to these port numbers: Local Address Foreign Address - 127.0.0.1:8005 0.0.0.0.0 That shows someone is using port 8005, so Tomcat won't be able to get it, resulting in the errors you see in the logs. The netstat -ano also gives you the PID of whoever's using that port; that's either another Tomcat, or possibly a Tomcat embedded in another product (e.g., VMware). You'll need to either kill the usurping process, or redefine your Tomcat's shutdown port to another value. So it appears that nothing is using the same port On the contrary, it shows that something *is* using one of the ports of interest. what is the correct way to respond in this forum Always post messages to the mailing list. Private ones will be returned ungraciously. BTW, a blank page in the browser is often the result of the ROOT webapp either not being present or failing to deploy properly. Make sure you have a ROOT webapp (case matters, even on Windows), and check the logs for any deployment errors. - 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 dies suddenly
Konstantin, Your response provides some interesting ideas. Remember that I had tried shutting Tomcat down by killing (kill -9 xxx where xxx is the process id) the java process and saw the same ending in the logs that I have been seeing when the system 'fails'. So it would seem that I could test the implementation of Chris' and Peter's ideas by simply killing the java process and see what the debugging code gives me. At least that looks like a baseline. Thanks for the help. Carl - Original Message - From: Konstantin Kolinko knst.koli...@gmail.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 1:17 PM Subject: Re: Tomcat dies suddenly 2010/2/12 Carl c...@etrak-plus.com: More details: the Dell 105 has an AMD processor and (currently) 8 GB memory. The T110 has a Xeon 3440 processor and 4 GB memory. The current Java version is 1.6.0_18-b07. The current Tomcat version is 6.0.24. Actually, 6.0.24 version *will* exit silently if it is terminated by a signal. To reproduce (on Windows): 1. Run Tomcat in a console window. 2. Press Ctrl+C 3. Tomcat shutdowns in several seconds, cleanly, but silently. That is because in 6.0.24 a VM shutdown hook was added that cleanly terminates logging subsystem (flushing all cached messages). The VM starts all shutdown hook threads at the same time and they run in parallel. Thus if Tomcat is being stopped through a hook, the logging subsystem has a chance to be already shut down at that time. I think that the same silent shutdown will occur if calling System.exit(), by the same reason. I do not know, what will happen if running Tomcat with jsvc on a Unix. (IIRC, jsvc calls the stop method in Bootstrap/Catalina, so Tomcat shuts down not through a hook and all messages should be present). The above is specific to 6.0.24. In 6.0.20 logs are forcibly flushed after each message is written, and log files are never explicitly closed. Best regards, Konstantin Kolinko - 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: Tomcat dies suddenly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carl, On 2/12/2010 2:42 PM, Carl wrote: Great ideas (did you see Chris's response with a way of testing the exit code?) [snip] There is no native code in the application (used to do a lot of work in C and I am familiar with mayhem of buffer overruns, pointer screwups, etc.) If you get really desperate, you can also run the jvm inside of strace and get ready for a huge log file. It's possible that you'll see the jvm fail on the same function call every time, and you'll get more information about the problem. strace will show you if a signal terminated the process, or if some other call killed it (like exec(), which would sure do a number on your JVM). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1s58ACgkQ9CaO5/Lv0PB8YQCgq0kuu87WVbPy0P40vFFHyPJW RUsAn1dzTKz2NTm7HAKAK7xeAWJS/2hd =2HBr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
Chuck, Oooo, that's interesting. Just tried kill -9 xxx (the process id of the java process) on one the servers not currently in production and it put nothing in the catalina.out file and nothing in the Slackware messages file. Time to test the ideas from Chris and Peter. Thanks for your insights. Carl - Original Message - From: Caldarale, Charles R chuck.caldar...@unisys.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 1:57 PM Subject: RE: Tomcat dies suddenly From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Subject: Re: Tomcat dies suddenly Actually, 6.0.24 version *will* exit silently if it is terminated by a signal. To reproduce (on Windows): 1. Run Tomcat in a console window. 2. Press Ctrl+C 3. Tomcat shutdowns in several seconds, cleanly, but silently. Not for me; I get the following in catalina.2010-02-12.log after entering CTRL-C: Feb 12, 2010 12:53:42 PM org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 This is Tomcat 6.0.24, JDK 1.6.0_14, Windows XP Pro 32-bit. - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat response chunk size
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred, On 2/12/2010 2:48 PM, fredk2 wrote: I have an old client that does not understand the Transfer-Encoding: chunked. My tomcat response is chunked with hex 2000 (8K and a little bit less via AJP: 1FF8). Do you mean that it's returned in chunks of 0x1FF8 bytes? Is there a way to configure Tomcat's chunk size to e.g 100K or another question where or why is it set to 8K? 100k? That sounds like a lot. Interestingly, in Tomcat4 there was an attribute allowChunking=false. The client can indicate that it doesn't support chunking by specifying HTTP/1.0 in the request line, and Tomcat shouldn't do chunking. If you are forcing chunking in some way in your code, though, you'll need to change that, too. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1tTsACgkQ9CaO5/Lv0PAKrwCeMM/iox+jViCNB4hQG4phrkP2 dqoAn0UjGb7u/QxRTIvwDrPwHefRY7GM =7ERk -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat dies suddenly
From: Carl [mailto:c...@etrak-plus.com] Subject: Re: Tomcat dies suddenly Just tried kill -9 xxx (the process id of the java process) on one the servers not currently in production and it put nothing in the catalina.out file and nothing in the Slackware messages file. The message won't be in catalina.out - look in catalina.-MM-dd.log. Also, what Windows does may not be the same as Linux. - 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 dies suddenly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carl, On 2/12/2010 3:03 PM, Carl wrote: Oooo, that's interesting. Just tried kill -9 xxx (the process id of the java process) on one the servers not currently in production and it put nothing in the catalina.out file and nothing in the Slackware messages file. Time to test the ideas from Chris and Peter. Maybe you should look around for a script like this: #!/bin/sh while true do sleep `random` killall -KILL java done :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1tb4ACgkQ9CaO5/Lv0PArjgCeJ5HUImbpQCTyBgqVFt16bqUB NtMAn2kuTh159ad00+Y059p3XqCj5tZr =cLAj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Socket Error in tomcat, white screen in browser
I apologize, I put across my last post a little misleading. The socket I showed before is the socket that Tomcat is using when I open it. Local Address Foreign Address - 127.0.0.1:8005 0.0.0.0.0 I am running tomcat through the loop back address. When I start the server then the above shows up in netstat -ano.When I close the server then it goes away. This means that the only program that is using this socket is the Tomcat that should be using it. So it isn't a problem with sockets (IP addresses and port numbers) as far as I can tell. BTW, a blank page in the browser is often the result of the ROOT webapp either not being present or failing to deploy properly. Make sure you have a ROOT webapp (case matters, even on Windows), and check the logs for any deployment errors. As far as this last comment, then I am aware that individual projects have a webapp folder and the tomcat program has its own webapp. When you talk about Root webapp, then you are talking about the Tomcat one right? What should be in this webapp folder? Here is what I have: Folders: docs examples host-manager manager Root Standard-examples Files: standard-examples.war -- View this message in context: http://old.nabble.com/Socket-Error-in-tomcat%2C-white-screen-in-browser-tp27567722p27568758.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: Tomcat dies suddenly
2010/2/12 Carl c...@etrak-plus.com: Chuck, Oooo, that's interesting. Just tried kill -9 xxx (the process id of the java process) on one the servers not currently in production and it put nothing in the catalina.out file and nothing in the Slackware messages file. Time to test the ideas from Chris and Peter. Thanks for your insights. Carl - Original Message - From: Caldarale, Charles R chuck.caldar...@unisys.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 1:57 PM Subject: RE: Tomcat dies suddenly From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Subject: Re: Tomcat dies suddenly Actually, 6.0.24 version *will* exit silently if it is terminated by a signal. To reproduce (on Windows): 1. Run Tomcat in a console window. 2. Press Ctrl+C 3. Tomcat shutdowns in several seconds, cleanly, but silently. Not for me; I get the following in catalina.2010-02-12.log after entering CTRL-C: Feb 12, 2010 12:53:42 PM org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 This is Tomcat 6.0.24, JDK 1.6.0_14, Windows XP Pro 32-bit. That depends on your luck. As I said, all hooks run in parallel. You can compare those messages with the ones printed when you shutdown through catalina.bat stop (aka shutdown.bat). Also, note that to disable buffering in log subsystem in 6.0.24 you can configure bufferSize=-1 for all your FileHandlers in logging.properties, see https://issues.apache.org/bugzilla/show_bug.cgi?id=48614#c5 6.0.25 and later will have log buffering turned off by default. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Socket Error in tomcat, white screen in browser
millerKiller wrote: I apologize, I put across my last post a little misleading. The socket I showed before is the socket that Tomcat is using when I open it. Local Address Foreign Address - 127.0.0.1:8005 0.0.0.0.0 I am running tomcat through the loop back address. When I start the server then the above shows up in netstat -ano.When I close the server then it goes away. This means that the only program that is using this socket is the Tomcat that should be using it. So it isn't a problem with sockets (IP addresses and port numbers) as far as I can tell. BTW, a blank page in the browser is often the result of the ROOT webapp either not being present or failing to deploy properly. Make sure you have a ROOT webapp (case matters, even on Windows), and check the logs for any deployment errors. As far as this last comment, then I am aware that individual projects have a webapp folder and the tomcat program has its own webapp. When you talk about Root webapp, then you are talking about the Tomcat one right? What should be in this webapp folder? Here is what I have: Folders: docs examples host-manager manager Root that should be ROOT, even under Windows Re-read what Chuck wrote above. As a matter of fact, re-read ALL the answers you have received, making sure that you do not read only half of them. netstat -aon not only shows you which ports are open/LISTENing, it also shows which process has them open. With the Task Manager, you can see which program matches which process-id. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
Andre, Thanks for the response. I have read almost all of your posts and realy enjoy the way to take problems apart. Keep on thinking. Thanks, Carl - Original Message - From: André Warnier a...@ice-sa.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 2:49 PM Subject: Re: Tomcat dies suddenly Carl wrote: .. a lot of messages, and I have not yet read all of them, but I sympathise with the predicament. I am very far from any kind of Java expertise, so just something that I vaguely seem to remember, although it may be from a very long time ago, not applicable, already mentioned by someone, and maybe not relevant at all.. I thus vaguely seem to remember that there existed some option to the JVM to provide a last resort amount of memory, only used if the JVM really ran out of memory, for the purpose of allowing at least some last-ditch desperate action to take place (like logging the catastrophe maybe). I don't remember how it's called or how it works, but maybe it will raise something in some expert's memory. - 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: Tomcat dies suddenly
Chris, Another great idea. I can deal with huge log files a whole lot better than continued failures. Thanks, Carl - Original Message - From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 3:01 PM Subject: Re: Tomcat dies suddenly -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carl, On 2/12/2010 2:42 PM, Carl wrote: Great ideas (did you see Chris's response with a way of testing the exit code?) [snip] There is no native code in the application (used to do a lot of work in C and I am familiar with mayhem of buffer overruns, pointer screwups, etc.) If you get really desperate, you can also run the jvm inside of strace and get ready for a huge log file. It's possible that you'll see the jvm fail on the same function call every time, and you'll get more information about the problem. strace will show you if a signal terminated the process, or if some other call killed it (like exec(), which would sure do a number on your JVM). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1s58ACgkQ9CaO5/Lv0PB8YQCgq0kuu87WVbPy0P40vFFHyPJW RUsAn1dzTKz2NTm7HAKAK7xeAWJS/2hd =2HBr -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
Re: tomcat response chunk size
thanks for the reply. I just remembered after i did my post that I can set in apache a BrowserMatch downgrade-1.0 for this client - works like a charm. out of curiosityany reason with 8K being a good number and where that would be set? Thanks again - Fred Christopher Schultz-2 wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred, On 2/12/2010 2:48 PM, fredk2 wrote: I have an old client that does not understand the Transfer-Encoding: chunked. My tomcat response is chunked with hex 2000 (8K and a little bit less via AJP: 1FF8). Do you mean that it's returned in chunks of 0x1FF8 bytes? Is there a way to configure Tomcat's chunk size to e.g 100K or another question where or why is it set to 8K? 100k? That sounds like a lot. Interestingly, in Tomcat4 there was an attribute allowChunking=false. The client can indicate that it doesn't support chunking by specifying HTTP/1.0 in the request line, and Tomcat shouldn't do chunking. If you are forcing chunking in some way in your code, though, you'll need to change that, too. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1tTsACgkQ9CaO5/Lv0PAKrwCeMM/iox+jViCNB4hQG4phrkP2 dqoAn0UjGb7u/QxRTIvwDrPwHefRY7GM =7ERk -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- View this message in context: http://old.nabble.com/tomcat-response-chunk-size-tp27568493p27568938.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: Socket Error in tomcat, white screen in browser
From: millerKiller [mailto:smille8...@hotmail.com] Subject: RE: Socket Error in tomcat, white screen in browser The socket I showed before is the socket that Tomcat is using when I open it. That's not a socket, it's a connection. So where are the other two ports Tomcat should also be listening on? There should be lines for 80 and 8009, for the same PID as the one on 8005. The Local Address for 80 and 8009 should be 0.0.0.0 (or the IPv6 equivalent); if those aren't present in the netstat -ano display, then Windows or some other security mechanism is preventing their use, and you won't be able to access Tomcat. I am running tomcat through the loop back address. Actually, you're not. Since the Connector elements have no address attribute, Tomcat should be listening on all IP addresses configured for the box, and netstat will show that as 0.0.0.0 (or the IPv6 equivalent). So it isn't a problem with sockets (IP addresses and port numbers) as far as I can tell. If 8005 is the only Tomcat port you're seeing in the netstat output, then it definitely *is* a problem with ports. (And don't confuse sockets with IP addresses and ports.) As far as this last comment, then I am aware that individual projects have a webapp folder and the tomcat program has its own webapp. That statement doesn't make sense. Each webapp is normally deployed under the Host appBase directory (default name is $CATALINA_BASE/webapps, although provisions exist for deploying them elsewhere. Tomcat does *not* have its own webapp; Tomcat uses whatever webapps it's been told to use or discovers by their placement under the appBase directory. When you talk about Root webapp I don't talk about Root webapp; the term is ROOT - as I said before, it is case-sensitive, even on Windows. you are talking about the Tomcat one right? No, I'm talking about whatever is deployed as ROOT. That may be the one that came with the Tomcat distribution, or it may be one that you've deployed in its place as the default webapp. What should be in this webapp folder? There is no webapp folder; do you mean webapps? Here is what I have: Folders: docs examples host-manager manager Root That should be ROOT, not Root. All of the above are part of the standard Tomcat distribution (other than Root, unless you really did mean ROOT). Standard-examples Files: standard-examples.war One of the above is wrong, since they must have the same casing. I presume the .war file is what you're building with Eclipse. You're going to need to be a lot more careful with your use of upper and lower case - this is critical. Windows tends to make people sloppy. - 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 dies suddenly
Chuck, Didn't know that but there is nothing in the catalina.2010-02-12.log except the lines from stopping Tomcat at 1:10AM this morning (the scripted restart after rolling out the changes from yesterday.) There is nothing in any of the other logs in the ~/tomcat/logs directory either. Thank you for the help. Carl - Original Message - From: Caldarale, Charles R chuck.caldar...@unisys.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 3:09 PM Subject: RE: Tomcat dies suddenly From: Carl [mailto:c...@etrak-plus.com] Subject: Re: Tomcat dies suddenly Just tried kill -9 xxx (the process id of the java process) on one the servers not currently in production and it put nothing in the catalina.out file and nothing in the Slackware messages file. The message won't be in catalina.out - look in catalina.-MM-dd.log. Also, what Windows does may not be the same as Linux. - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
Carl wrote: Andre, Thanks for the response. I have read almost all of your posts and realy enjoy the way to take problems apart. Keep on thinking. I'm not quite sure how to take the above answer.. So, just in case, and maybe to my own ultimate embarassment, I want to indicate that I was serious. I seem to remember cases where an application at the point of dying, would have very much liked to log a last desperate message to indicate the situation, but did not even have the resources left to be able to do so. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
Chris, That script would also (I think) kill the VisualJVM and my small java server, wouldn't it. That is not happening... those are staying very much alive, just Tomcat goes down. Thanks, Carl - Original Message - From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 3:10 PM Subject: Re: Tomcat dies suddenly -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carl, On 2/12/2010 3:03 PM, Carl wrote: Oooo, that's interesting. Just tried kill -9 xxx (the process id of the java process) on one the servers not currently in production and it put nothing in the catalina.out file and nothing in the Slackware messages file. Time to test the ideas from Chris and Peter. Maybe you should look around for a script like this: #!/bin/sh while true do sleep `random` killall -KILL java done :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1tb4ACgkQ9CaO5/Lv0PArjgCeJ5HUImbpQCTyBgqVFt16bqUB NtMAn2kuTh159ad00+Y059p3XqCj5tZr =cLAj -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
tomcat 6 on solaris losing cookies
-- View this message in context: http://old.nabble.com/tomcat-6-on-solaris-losing-cookies-tp27569008p27569008.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: Tomcat dies suddenly
Konstantin, When I shut Tomcat down using shutdown.sh, I see these messages (from 1:10AM this morning): Feb 12, 2010 1:10:02 AM org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 Feb 12, 2010 1:10:02 AM org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-8443 Feb 12, 2010 1:10:02 AM org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-443 Feb 12, 2010 1:10:03 AM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina Feb 12, 2010 1:10:03 AM org.apache.coyote.http11.Http11Protocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8080 Feb 12, 2010 1:10:03 AM org.apache.coyote.http11.Http11Protocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8443 Feb 12, 2010 1:10:03 AM org.apache.coyote.http11.Http11Protocol destroy INFO: Stopping Coyote HTTP/1.1 on http-443 in catalina.-MM-DD.log but I never see any messages when I do kill -9 xxx to kill the java process. Thanks, Carl - Original Message - From: Konstantin Kolinko knst.koli...@gmail.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 3:19 PM Subject: Re: Tomcat dies suddenly 2010/2/12 Carl c...@etrak-plus.com: Chuck, Oooo, that's interesting. Just tried kill -9 xxx (the process id of the java process) on one the servers not currently in production and it put nothing in the catalina.out file and nothing in the Slackware messages file. Time to test the ideas from Chris and Peter. Thanks for your insights. Carl - Original Message - From: Caldarale, Charles R chuck.caldar...@unisys.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 1:57 PM Subject: RE: Tomcat dies suddenly From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Subject: Re: Tomcat dies suddenly Actually, 6.0.24 version *will* exit silently if it is terminated by a signal. To reproduce (on Windows): 1. Run Tomcat in a console window. 2. Press Ctrl+C 3. Tomcat shutdowns in several seconds, cleanly, but silently. Not for me; I get the following in catalina.2010-02-12.log after entering CTRL-C: Feb 12, 2010 12:53:42 PM org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 This is Tomcat 6.0.24, JDK 1.6.0_14, Windows XP Pro 32-bit. That depends on your luck. As I said, all hooks run in parallel. You can compare those messages with the ones printed when you shutdown through catalina.bat stop (aka shutdown.bat). Also, note that to disable buffering in log subsystem in 6.0.24 you can configure bufferSize=-1 for all your FileHandlers in logging.properties, see https://issues.apache.org/bugzilla/show_bug.cgi?id=48614#c5 6.0.25 and later will have log buffering turned off by default. Best regards, Konstantin Kolinko - 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: tomcat 6 on solaris losing cookies
Appears to be losing more than just cookies... Anybody have lemon juice so we can read the hidden text? - 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. -Original Message- From: George Baxter [mailto:gbax...@shutterfly.com] Sent: 2010 February 12, Friday 14:39 To: users@tomcat.apache.org Subject: tomcat 6 on solaris losing cookies -- View this message in context: http://old.nabble.com/tomcat-6-on- solaris-losing-cookies-tp27569008p27569008.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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
Andre, Take my comment as a compliment because that is the way it was meant... you have helped a lot of people on this least and I, for one, really appreciate that. I was waiting to see if someone could give me an idea how to implement what you remembered and, if not, then I would google around to see if I could find it myself. Thanks, Carl - Original Message - From: André Warnier a...@ice-sa.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 3:34 PM Subject: Re: Tomcat dies suddenly Carl wrote: Andre, Thanks for the response. I have read almost all of your posts and realy enjoy the way to take problems apart. Keep on thinking. I'm not quite sure how to take the above answer.. So, just in case, and maybe to my own ultimate embarassment, I want to indicate that I was serious. I seem to remember cases where an application at the point of dying, would have very much liked to log a last desperate message to indicate the situation, but did not even have the resources left to be able to do so. - 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: Tomcat dies suddenly
Carl wrote: Andre, Take my comment as a compliment because that is the way it was meant... you have helped a lot of people on this least and I, for one, really appreciate that. I was waiting to see if someone could give me an idea how to implement what you remembered and, if not, then I would google around to see if I could find it myself. A flash came back to me in the meantime. Searching Google for java +oom +parachute yields some interesting links, also if you are into sky-diving in exotic places. But I am afraid that the main reason I remembered, was that I happened to suggest something like that myself a while ago on a Tomcat forum. But then also, it seems someone else much more qualified than I am had the same idea and implemented it in the Tomcat NIO connector. So maybe there is some coding idea there that may still help. That is, if your problem is an OOM of course. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat 6 on solaris losing cookies
Yes, yes, I accidentally hit return instead of tab when jumping from subject line to message.. mea culpa! I filled in the text with an edit later! n828cl wrote: Appears to be losing more than just cookies... Anybody have lemon juice so we can read the hidden text? - 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. -Original Message- From: George Baxter [mailto:gbax...@shutterfly.com] Sent: 2010 February 12, Friday 14:39 To: users@tomcat.apache.org Subject: tomcat 6 on solaris losing cookies -- View this message in context: http://old.nabble.com/tomcat-6-on- solaris-losing-cookies-tp27569008p27569008.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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- View this message in context: http://old.nabble.com/tomcat-6-on-solaris-losing-cookies-tp27569008p27569192.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: Tomcat dies suddenly
Carl -
I did have something like this happen to me - not with Tomcat but with
another JEE container. The container would run for a while, without
incident, then suddenly simply die, with nothing in any log, and not on any
apparent time schedule.
We had some code that was manipulating LDAP that had a leak in it. For each
leaked connection, we had an open file descriptor that never went away,
until the process went away. If memory serves, we finally found it by
looking at entries in /proc/{pid of jvm}/fd, doing a bunch of find . | wc
and watching that over time.
I hope this is of some help. Good luck.
Donn
On Fri, Feb 12, 2010 at 3:46 PM, Carl c...@etrak-plus.com wrote:
Andre,
Take my comment as a compliment because that is the way it was meant... you
have helped a lot of people on this least and I, for one, really appreciate
that.
I was waiting to see if someone could give me an idea how to implement what
you remembered and, if not, then I would google around to see if I could
find it myself.
Thanks,
Carl
- Original Message - From: André Warnier a...@ice-sa.com
To: Tomcat Users List users@tomcat.apache.org
Sent: Friday, February 12, 2010 3:34 PM
Subject: Re: Tomcat dies suddenly
Carl wrote:
Andre,
Thanks for the response.
I have read almost all of your posts and realy enjoy the way to take
problems apart.
Keep on thinking.
I'm not quite sure how to take the above answer..
So, just in case, and maybe to my own ultimate embarassment, I want to
indicate that I was serious. I seem to remember cases where an application
at the point of dying, would have very much liked to log a last desperate
message to indicate the situation, but did not even have the resources left
to be able to do so.
-
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: tomcat 6 on solaris losing cookies
On Fri, Feb 12, 2010 at 12:55 PM, George Baxter gbax...@shutterfly.com wrote: Yes, yes, I accidentally hit return instead of tab when jumping from subject line to message.. mea culpa! I filled in the text with an edit later! I, for one, welcome our vistor from the future, where emails can be retroactively edited. And I hope to share in this technology -- there's some stuff I sent in 1996, particularly, that could use some serious reworking. Greetings from 2010! -- Hassan Schroeder hassan.schroe...@gmail.com twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
Donn Aiken wrote:
...
For each
leaked connection, we had an open file descriptor that never went away,
until the process went away. If memory serves, we finally found it by
looking at entries in /proc/{pid of jvm}/fd, doing a bunch of find . | wc
and watching that over time.
As another flash, another utility that may be of help here is lsof.
Just the list of options is scary and it takes an engineering degree to
handle, but the least it can do is show you which sockets, files and
such things are used by what.
As a command-line tool, it is easy to write a small shell script with a
loop calling lsof every 15 seconds e.g., dumping the result to a file
which you could examine when your Tomcat goes boom.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
Chris, I was preparing to try out your checking the jvm exit code and noticed (drum roll) that this morning's failure left a core dump in the tomcat/bin directory. Opening it with gdb -c yielded: This GDB was configured as x86_64-slackware-linux. (no debugging symbols found) Core was generated by `/usr/local/java/bin/java -Djava.util.logging.config.file=/usr/local/tomcat/conf'. Program terminated with signal 11, Segmentation fault. This Tomcat is straight out of the box except for some modifications to JAVA_OPTS in tomcat/bin/catalina.sh and opening up ports and turning on SSL in tomcat/conf/server.xml. There is a logging.properties file in tomcat/conf. How does this line: `/usr/local/java/bin/java -Djava.util.logging.config.file=/usr/local/tomcat/conf' know that it is supposed to use the logging.properties file if that is the problem? Or, is there some other problem? Now, this is embarrassing: I just checked the other server and it also has a core file with the date and time of the last failure in the tomcat/bin directory. And, it shows a seg fault at exactly the same code. This might be a winner... we certainly know it killed the java process. Thanks, Carl - Original Message - From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 3:01 PM Subject: Re: Tomcat dies suddenly -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carl, On 2/12/2010 2:42 PM, Carl wrote: Great ideas (did you see Chris's response with a way of testing the exit code?) [snip] There is no native code in the application (used to do a lot of work in C and I am familiar with mayhem of buffer overruns, pointer screwups, etc.) If you get really desperate, you can also run the jvm inside of strace and get ready for a huge log file. It's possible that you'll see the jvm fail on the same function call every time, and you'll get more information about the problem. strace will show you if a signal terminated the process, or if some other call killed it (like exec(), which would sure do a number on your JVM). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1s58ACgkQ9CaO5/Lv0PB8YQCgq0kuu87WVbPy0P40vFFHyPJW RUsAn1dzTKz2NTm7HAKAK7xeAWJS/2hd =2HBr -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
RE: Tomcat dies suddenly
From: Carl [mailto:c...@etrak-plus.com] Subject: Re: Tomcat dies suddenly How does this line: `/usr/local/java/bin/java - Djava.util.logging.config.file=/usr/local/tomcat/conf' know that it is supposed to use the logging.properties file if that is the problem? It doesn't know. The command line parameter should be: -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties Perhaps the display is just a truncation, since there should be several additional command line parameters beyond that one. Use JConsole to see if the full set of properties are present when Tomcat is running normally. - 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.
RE: tomcat 6 on solaris losing cookies
Since nabble posts (but not edits) are also being sent to tomcat user mailing lists, I'll repost my question and apologize for the spam now! Hello, We're running into an issue with tomcat 6.0.18 running on solaris. Occasionally a request will come through that has cookies in the header, but the request.getCookies() returns no cookies. This causes the user to lose session since even the JSESSIONID cookie is not recognized, and of course all our custom cookies are lost. It seems to happen randomly, across our web site, and varies in frequency from every 2-3 requests to over 200 requests before it happens again. There's no change to the cookie values (or very little) between requests. In addition, this only seems to be a problem on solaris. Running on MacOSx or Linux and we don't see the issue. Also, we don't have the problem in Tomcat 5.5. Any ideas what might be happening? Thanks. -- View this message in context: http://old.nabble.com/tomcat-6-on-solaris-losing-cookies-tp27569008p27569854.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: tomcat response chunk size
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred, On 2/12/2010 3:31 PM, fredk2 wrote: I just remembered after i did my post that I can set in apache a BrowserMatch downgrade-1.0 for this client - works like a charm. Sounds good. out of curiosityany reason with 8K being a good number and where that would be set? I have no idea where the number 8k is coming from. It's as good a number as any other, I guess! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1zxMACgkQ9CaO5/Lv0PAHNgCffq0JRQavGJqeKGrfZnuwcMWe 7GcAniQ4Jm+OAb+5Qk1fzm4Ab3yOs3i8 =vwtH -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
Chuck, Darn, I thought we were onto something here but, as you suspected, the line contains a lot of parameters and was truncated. So, now, I think we know the JVM is seg faulting, we just don't know where or why. I'm guessing we have to somehow get a stack trace at the point of failure... any idea how I can get one? Or, is there a better way? Thanks, Carl - Original Message - From: Caldarale, Charles R chuck.caldar...@unisys.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 4:52 PM Subject: RE: Tomcat dies suddenly From: Carl [mailto:c...@etrak-plus.com] Subject: Re: Tomcat dies suddenly How does this line: `/usr/local/java/bin/java - Djava.util.logging.config.file=/usr/local/tomcat/conf' know that it is supposed to use the logging.properties file if that is the problem? It doesn't know. The command line parameter should be: -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties Perhaps the display is just a truncation, since there should be several additional command line parameters beyond that one. Use JConsole to see if the full set of properties are present when Tomcat is running normally. - 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 dies suddenly
Can it be hardware? Do you have ways to monitor temperature in your box? http://www.bitwizard.nl/sig11/ Best regards, Konstantin Kolinko 2010/2/13 Carl c...@etrak-plus.com: Chuck, Darn, I thought we were onto something here but, as you suspected, the line contains a lot of parameters and was truncated. So, now, I think we know the JVM is seg faulting, we just don't know where or why. I'm guessing we have to somehow get a stack trace at the point of failure... any idea how I can get one? Or, is there a better way? Thanks, Carl - Original Message - From: Caldarale, Charles R chuck.caldar...@unisys.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 4:52 PM Subject: RE: Tomcat dies suddenly From: Carl [mailto:c...@etrak-plus.com] Subject: Re: Tomcat dies suddenly How does this line: `/usr/local/java/bin/java - Djava.util.logging.config.file=/usr/local/tomcat/conf' know that it is supposed to use the logging.properties file if that is the problem? It doesn't know. The command line parameter should be: -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties Perhaps the display is just a truncation, since there should be several additional command line parameters beyond that one. Use JConsole to see if the full set of properties are present when Tomcat is running normally. - Chuck - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
Konstantin, Both servers (T105 and T110) have temperature monitoring. I pulled and sent some information (don't remember how I got it) to Dell and they said the system was operating in a normal range. Also, the fact that it occurs on two different, brand new boxes makes me think it is unlikely to be the culprit. Thanks, Carl - Original Message - From: Konstantin Kolinko knst.koli...@gmail.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 5:08 PM Subject: Re: Tomcat dies suddenly Can it be hardware? Do you have ways to monitor temperature in your box? http://www.bitwizard.nl/sig11/ Best regards, Konstantin Kolinko 2010/2/13 Carl c...@etrak-plus.com: Chuck, Darn, I thought we were onto something here but, as you suspected, the line contains a lot of parameters and was truncated. So, now, I think we know the JVM is seg faulting, we just don't know where or why. I'm guessing we have to somehow get a stack trace at the point of failure... any idea how I can get one? Or, is there a better way? Thanks, Carl - Original Message - From: Caldarale, Charles R chuck.caldar...@unisys.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, February 12, 2010 4:52 PM Subject: RE: Tomcat dies suddenly From: Carl [mailto:c...@etrak-plus.com] Subject: Re: Tomcat dies suddenly How does this line: `/usr/local/java/bin/java - Djava.util.logging.config.file=/usr/local/tomcat/conf' know that it is supposed to use the logging.properties file if that is the problem? It doesn't know. The command line parameter should be: -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties Perhaps the display is just a truncation, since there should be several additional command line parameters beyond that one. Use JConsole to see if the full set of properties are present when Tomcat is running normally. - Chuck - 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
Character encoding for POST x-www-form-urlencoding (a success story)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
My company recently decided to alter our password complexity
requirements for our webapp, and I got to implement the changes. What fun!
We use a regular expression to enforce our password complexity, and it
needed to be changed. Since we are starting to branch-out into
populations that aren't necessarily using written English everywhere, I
chose to change our naive [a-z]- and [A-Z]-type checking to a mroe
enlightened \p{Ll} and \p{Lu}, respectively. (Readers' note: jakarta-oro
does not support this notation, so you'll want to use Java's built-in
regular expression support to do this).
Anyhow, when making changes to things security-related, it pays to test
/everything/, so I grabbed 4 other people from my group and had them
each test 15 sample passwords against our 6 different forms that accept
password-change entry. Everything went fine.
Except when I then tried to login from our home page with the password
1πππ (that's a '1' digit followed by 7 Greek Pi characters, in
case your email reader can't render that), and I got a failure. I
figured I must have fat-fingered something, so I tried again and all was
well.
My spidey-sense tingling, I logged-out and repeated the process: again,
my first login attempt was unsuccessful, while the second was. Hmm. Upon
closer inspection, our opening page is a static HTML file served by
Apache httpd -- no Tomcat involvement. After a failed login, a page that
looks exactly like the home page is sent to the user, but it's
different: /and/ it's served by Tomcat.
The difference was that the original request's response (for
/index.html) had a Content-Type of text/html, while the failed login
had a response Content-Type of text/html; charset=UTF-8.
It's out old pal what's the default encoding, again? coming back to
haunt me, and here I am telling people on this list that they just don't
understand the history of the web and how to do things properly.
Evidently, I wasn't doing them properly, either.
All those complaints about the way that URL-encoded GET parameters can
get messed up based upon Content-Type and encoding guesses, etc. and the
solution is just to use POST is, well, only half the truth. Yes, POST
gets you away from the browser's preference for what encoding to use
before URL-encoding the bytes, but, with POST the Content-Type is
application/x-www-form-urlencoded, which means there's no charset
associated with it. :(
So, what's to be done?
Well, I immediately thought of two solutions:
meta http-equiv=Content-Type content=text/html; charset=UTF-8 /
and
form accept-charset=UTF-8
Knowing that web browsers are notoriously inconsistent with one another
regarding certain things, I was sure that I'd have a giant mess when it
came to testing, and that I'd have to figure out how to trick each
version of each browser into doing my bidding.
First, I had to make sure that they all /failed/ in the same way (that
is to say, that the login failed the way I expected it to fail), then I
had to see what magical incantations would be necessary to actually get
the login to succeed.
I'm happy to report that, for /all/ of the following browsers, */both/*
solutions worked!
Mozilla Firefox 2.0
Mozilla Firefox 3.0
Mozilla Firefox 3.5
Mozilla Firefox 3.6
Opera 9.6
Opera 10.10
Apple Safari 3.2
Apple Safari 4.0
Google Chrome 4.0
MSIE 6.0
MSIE 7.0
MSIE 8.0
I'm inclined to use the form accept-charset=UTF-8 solution, because
that does not involve lying to the browser about the encoding of the
actual HTML document. Instead, I'd rather advertise that I will only
accept UTF-8 encoding and leave it at that. Sadly, the client still
doesn't tell me that the underlying encoding being used to urlencode the
POST parameters is UTF-8, but at least they're doing what I want them to
do, and they all agree on behavior!
So, score 1 for standards, at least in this instance.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkt11PoACgkQ9CaO5/Lv0PC+OACgtobt70NWFxYJzcRt5r0zXlaN
tYEAn0ZYnB/oehIoZR0NUs7Q/4mOux7x
=U0Wt
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carl, On 2/12/2010 4:44 PM, Carl wrote: Now, this is embarrassing: I just checked the other server and it also has a core file with the date and time of the last failure in the tomcat/bin directory. And, it shows a seg fault at exactly the same code. This might be a winner... we certainly know it killed the java process. So, this now, to me, narrows this down to two possibilities: 1. A JVM bug 2. A hardware problem That is, if you really aren't running any native code. But, if you were, it would be showing up in the code dump, right?! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt11YMACgkQ9CaO5/Lv0PC/ZwCcCdB3k1ARO5uhxneWilt3wkox n/4AniRJb/t3Xd9FgKQecXHN7UyFP5RQ =s/EK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carl, On 2/12/2010 4:59 PM, Carl wrote: Darn, I thought we were onto something here but, as you suspected, the line contains a lot of parameters and was truncated. So, now, I think we know the JVM is seg faulting, we just don't know where or why. I'm guessing we have to somehow get a stack trace at the point of failure... any idea how I can get one? Or, is there a better way? I believe you can do roughly this with gdb (from memory): $ gdb core-file gdb) where (boom: your stack trace goes here) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt11bwACgkQ9CaO5/Lv0PBUCgCfbR2f2IXwFq7ile8biFNjsXOH opEAnj7gYfb2jfQDtwIcl5atUpyYG8au =im6P -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat dies suddenly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 2/12/2010 3:34 PM, André Warnier wrote: Carl wrote: Andre, Thanks for the response. I have read almost all of your posts and realy enjoy the way to take problems apart. Keep on thinking. I'm not quite sure how to take the above answer.. So, just in case, and maybe to my own ultimate embarassment, I want to indicate that I was serious. I seem to remember cases where an application at the point of dying, would have very much liked to log a last desperate message to indicate the situation, but did not even have the resources left to be able to do so. Are you talking about this? http://tomcat.apache.org/tomcat-6.0-doc/config/http.html (search for oomParachute) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkt11hkACgkQ9CaO5/Lv0PA40gCfaqBCAz8wq2k6W3SH3gKIlF7q xMQAnjnynEOuXlosG/v2jWHVx5akaQWo =ODoh -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 6 on solaris losing cookies
2010/2/13 George Baxter gbax...@shutterfly.com: Hello, We're running into an issue with tomcat 6.0.18 running on solaris. Occasionally a request will come through that has cookies in the header, but the request.getCookies() returns no cookies. How do you observe that? You mean that it is present in HttpServletRequest.getHeaders(Cookie) ? This causes the user to lose session since even the JSESSIONID cookie is not recognized, and of course all our custom cookies are lost. It seems to happen randomly, across our web site, and varies in frequency from every 2-3 requests to over 200 requests before it happens again. There's no change to the cookie values (or very little) between requests. In addition, this only seems to be a problem on solaris. Running on MacOSx or Linux and we don't see the issue. Also, we don't have the problem in Tomcat 5.5. Any other details on your configuration? What connectors are you using? HTTP/AJP? Nio/Bio/Apr? (usually some org.apache.coyote.* class is mentioned in the startup log in a Starting Coyote .. message) Do you have Apache HTTPD in front of Tomcat? Do you have HTTP proxies around? Are failing requests coming from some specific client? Are they coming from some specific browser? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Character encoding for POST x-www-form-urlencoding (a success story)
Very nice work, Thank you for the sharing.
On Fri, Feb 12, 2010 at 11:23 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
My company recently decided to alter our password complexity
requirements for our webapp, and I got to implement the changes. What fun!
We use a regular expression to enforce our password complexity, and it
needed to be changed. Since we are starting to branch-out into
populations that aren't necessarily using written English everywhere, I
chose to change our naive [a-z]- and [A-Z]-type checking to a mroe
enlightened \p{Ll} and \p{Lu}, respectively. (Readers' note: jakarta-oro
does not support this notation, so you'll want to use Java's built-in
regular expression support to do this).
Anyhow, when making changes to things security-related, it pays to test
/everything/, so I grabbed 4 other people from my group and had them
each test 15 sample passwords against our 6 different forms that accept
password-change entry. Everything went fine.
Except when I then tried to login from our home page with the password
1πππ (that's a '1' digit followed by 7 Greek Pi characters, in
case your email reader can't render that), and I got a failure. I
figured I must have fat-fingered something, so I tried again and all was
well.
My spidey-sense tingling, I logged-out and repeated the process: again,
my first login attempt was unsuccessful, while the second was. Hmm. Upon
closer inspection, our opening page is a static HTML file served by
Apache httpd -- no Tomcat involvement. After a failed login, a page that
looks exactly like the home page is sent to the user, but it's
different: /and/ it's served by Tomcat.
The difference was that the original request's response (for
/index.html) had a Content-Type of text/html, while the failed login
had a response Content-Type of text/html; charset=UTF-8.
It's out old pal what's the default encoding, again? coming back to
haunt me, and here I am telling people on this list that they just don't
understand the history of the web and how to do things properly.
Evidently, I wasn't doing them properly, either.
All those complaints about the way that URL-encoded GET parameters can
get messed up based upon Content-Type and encoding guesses, etc. and the
solution is just to use POST is, well, only half the truth. Yes, POST
gets you away from the browser's preference for what encoding to use
before URL-encoding the bytes, but, with POST the Content-Type is
application/x-www-form-urlencoded, which means there's no charset
associated with it. :(
So, what's to be done?
Well, I immediately thought of two solutions:
meta http-equiv=Content-Type content=text/html; charset=UTF-8 /
and
form accept-charset=UTF-8
Knowing that web browsers are notoriously inconsistent with one another
regarding certain things, I was sure that I'd have a giant mess when it
came to testing, and that I'd have to figure out how to trick each
version of each browser into doing my bidding.
First, I had to make sure that they all /failed/ in the same way (that
is to say, that the login failed the way I expected it to fail), then I
had to see what magical incantations would be necessary to actually get
the login to succeed.
I'm happy to report that, for /all/ of the following browsers, */both/*
solutions worked!
Mozilla Firefox 2.0
Mozilla Firefox 3.0
Mozilla Firefox 3.5
Mozilla Firefox 3.6
Opera 9.6
Opera 10.10
Apple Safari 3.2
Apple Safari 4.0
Google Chrome 4.0
MSIE 6.0
MSIE 7.0
MSIE 8.0
I'm inclined to use the form accept-charset=UTF-8 solution, because
that does not involve lying to the browser about the encoding of the
actual HTML document. Instead, I'd rather advertise that I will only
accept UTF-8 encoding and leave it at that. Sadly, the client still
doesn't tell me that the underlying encoding being used to urlencode the
POST parameters is UTF-8, but at least they're doing what I want them to
do, and they all agree on behavior!
So, score 1 for standards, at least in this instance.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkt11PoACgkQ9CaO5/Lv0PC+OACgtobt70NWFxYJzcRt5r0zXlaN
tYEAn0ZYnB/oehIoZR0NUs7Q/4mOux7x
=U0Wt
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
Sincerely yours and Best Regards,
Xie Xiaodong
Re: Tomcat dies suddenly
Carl, I would just like to mention that in 90% of the cases where I have seen a Seg Fault, it was due to the attempted execution of a piece of binary code not meant for the current platform. (It's been a while since I've seen one though.) I have no idea what piece of native code would be used by the JVM only under heavy load, but would it be possible that such a piece, compiled for another architecture, may have slipped in your JVM package ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
