Re: Tomcat hangs
on 2/12/04 11:17 AM, Shapira, Yoav wrote: > Have you tried this with a more recent tomcat version? No. I've not been able to isolate the bug well enough to reproduce it, so there's nothing to test with. I have only observed the vulnerability in our current production server. I've since disabled access for the IP range that was generating the problematic http requests. Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat hangs
Hello, I posted a query last week about Tomcat 4.0.6 under OS X hanging, but haven't seen any response (was: SocketInputStream hanging Tomcat 4.0.6). Is there anything more I can do ( more information I can provide, for example ) to illicit feedback from the list or the developer of the code section? This appears to be a vulnerability in Tomcat 4.0.6 - 4.1.x. - The problem: Stage 1: According to the catalina log, SocketInputStream.readHeader is throwing ArrayIndexOutOfBounds exceptions at line 487. Stage 2: Successive throws eventually cause Tomcat to respond to all requests with error 400: bad request. The original http requests stemmed from one IP range, whose access I've since disabled. I'm very concerned that a single user was able to bring down the server. Does anyone have a feel for what's happening here? Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SocketInputStream hanging Tomcat 4.0.6
Help! On a production system that's been rock-solid for 18 months, Tomcat is
suddenly hanging on a daily basis!
Before the server hangs, we're logging runtime exceptions from
SocketInputStream.readHeader: the log records ArrayIndexOutOfBounds
exceptions every second for a few hours, then the server responds to every
subsequent request with a 400 "Bad Header" response, ie. hangs.
The same/similar problem was reported a year ago, see
http://www.mail-archive.com/[EMAIL PROTECTED]/msg85861.html
Can anyone shed light on what is happening? Or suggest a workaround/fix?
Thanks,
Chris
Sample stack trace:
2004-02-04 22:20:06 HttpProcessor[8080][14] process.parse
java.lang.ArrayIndexOutOfBoundsException
at
org.apache.catalina.connector.http.SocketInputStream.readHeader(SocketInputS
tream.java:487)
at
org.apache.catalina.connector.http.HttpProcessor.parseHeaders(HttpProcessor.
java:579)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:
977)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1125
)
at java.lang.Thread.run(Thread.java:491)
---
SocketInputStream.java line 487:
---
while (!eol) {
// if the buffer is full, extend it
if (readCount >= maxRead) {
if ((2 * maxRead) <= HttpHeader.MAX_VALUE_SIZE) {
char[] newBuffer = new char[2 * maxRead];
System.arraycopy(header.value, 0, newBuffer, 0,
maxRead);
header.value = newBuffer;
maxRead = header.value.length;
} else {
throw new IOException
(sm.getString("requestStream.readline.toolong"));
}
}
// We're at the end of the internal buffer
if (pos >= count) {
// Copying part (or all) of the internal buffer to the line
// buffer
int val = read();
if (val == -1)
throw new IOException
(sm.getString("requestStream.readline.error"));
pos = 0;
readStart = 0;
}
if (buf[pos] == CR) {
} else if (buf[pos] == LF) {
eol = true;
} else {
// FIXME : Check if binary conversion is working fine
int ch = buf[pos] & 0xff;
header.value[readCount] = (char) ch; // <--- LINE 487
readCount++;
}
pos++;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: IE 6 causes broken pipe exception
on 9/20/03 11:07 AM, Anton Tagunov wrote: > Hello Chris! > > CR> IE 6 is sending two GET requests for each .mp3 file. I haven't tested the > CR> behavior on IE 5.x or other plugin-handled mime types. [snip] > CR> So, two questions for the karmically kind: > > CR> 1) Any bright ideas on a workaround for the user-agent: contype GET? > > Yes, this can be handled by servicing your mp3 files via your own > servlet. I could check for the user-agent: contype and then probably > forwar the request or invoke RequestDispatcher. You may wrap the > original request in the wrapper provided by the Servlet 2.3 API > substituting the method GET with HEAD. (Do I remember it all > correctly?) Remapping the contype onto a HEAD seems like a good solution. > A more stratagic descision would be to build this into the Tomcat. > I've entered an enahncement request to Tomcat bug database > including your mail there. You may augment this enhancment > request at > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23294 Thanks. I'll have a look. > CR> At > CR> present it's double-banging my server for 100-200k files. Is there a > context > CR> level mechanism for filtering, ie, blocking, requests based on headers? > > CR> 2) Is this more properly a development issue? I see workarounds in the > CR> 4.1.27 and 5.x source to ignore "Broken pipe" exceptions > > This seems perfectly sane, the client may terminate connection for a > multitude of reasons. > CR> and the multiple GET is apparently rooted in kludges from browser > CR> 4.x days -- > Hmm, what did you mean, Chris? The contype GET has its origins in the days when servers had inconsistent support for the HEAD method and continues to pop up under various guises in IE 4, 5 + 6. So the behaviour has been around for a long, long time. I'm wildly speculating that the workarounds to suppress broken pipe exceptions might be, at least in part, motivated by the excess of broken pipes caused by IE's data-sniffing technique. cheers, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disabling session management (FAQ not enough)
on 9/18/03 1:29 PM, Greg Ward wrote: > I would like to completely disable Tomcat session management. I'm in > > You might try: Cheers, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IE 6 causes broken pipe exception
Here's a followup to: >Subject: DefaultServlet throws a LOT of broken pipe exceptions on mp3s. --- I found the cause of my java.io.IOException "Broken pipe" errors. IE 6 is sending two GET requests for each .mp3 file. I haven't tested the behavior on IE 5.x or other plugin-handled mime types. The first GET sets the request header: user-agent = contype and is a Microsoft (ie, non-standard) attempt at data-sniffing intended to get just the header information. Tomcat 4.x starts sending the content data, but IE resets/drops the connection after 30-50k (100-500 ms), generating a "Broken pipe" exception. IE then sends a second request for the content using: user-agent=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) which completes. [see Microsoft Knowledge Base Articles: KB 293792, KB 254337, KB 310388. Note: KB 310388 describes a fix for multiple posts in IE 6 SP1 (service pack 1). Tests from an IE 6 SP1 client however still demonstrate the multiple GETs. I'm still trying to determine if the broken pipe GET is the cause of the unreliable caching behaving I'm seeing in IE 6 (symptom: IE 6 clients are downloading about 10x vs. Netscape/Safari clients; few if any 304 responses). --- So, two questions for the karmically kind: 1) Any bright ideas on a workaround for the user-agent: contype GET? At present it's double-banging my server for 100-200k files. Is there a context level mechanism for filtering, ie, blocking, requests based on headers? 2) Is this more properly a development issue? I see workarounds in the 4.1.27 and 5.x source to ignore "Broken pipe" exceptions and the multiple GET is apparently rooted in kludges from browser 4.x days -- but I got no hits for "user-agent contype" in a google of the tomcat archives. Cheers, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: init servlet loaded twice
I've noticed that load-on-startup also causes an extra instances of jsps. I came across another thread on multiple inits (Sun forum?). The gist was that it's legitimate for the container to instantiate several of your class. Makes sense if you think about it. It's a "class" after all. Chris on 9/18/03 12:38 PM, Phillip Qin wrote: > I was looking at my webapp log this afternoon. I use tomcat + log4j + > struts. In the log, I found that my InitServlet was loaded twice. One under > Thread-xxx, the other under HostConfig[localhost]. Could any body please > explain? > > PQ > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DefaultServlet throws a LOT of broken pipe exceptions on mp3s
Thanks for both responses. I've got a better idea now what to test. Remy's suggestion of extra bytes being written might plausible, espec. as these are Mac OS files. Sometimes the Apple resource fork messes with little server minds. In the near future, I'll also upgrade to 5.x and move audio + photos onto a different box, but that's a few regression tests away yet. I have been using telnet, jmeter and a RequestDumper valve, but I haven't set up a test plan to bang on the mp3s. Might be worth simulating 20 users on a random timer and see what happens. Anyway, thanks for the help. I'll post back any further findings in case someone's interested. Cheers, Chris on 9/18/03 5:10 AM, Tim Funk wrote: > I think in > 4.1.24 those messages have been eliminated. Do you get the same > errors with wget or similar? It could be the player is sending wacky requests. > > Otherwise - at 4.0.4 - I'm out of ideas. > > -Tim > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DefaultServlet throws a LOT of broken pipe exceptions on mp3s
That's what I thought at first, but this happens 80-90% of the time on the 100k+ files. There are two files on the same page, one 100-200k dialog, and a 10-30k sentence. It seems to me unlikely the users are hitting stop that quickly and that often. These are reasonably fast university connections in a class setting. Could it be another request hitting the server? Mishandling of partial GETs? Related, the catalina Logger doesn't seem to take Filters (or am I missing something?). I'd like to keep this cruft (in the meantime) out of the log. Chris on 9/18/03 3:57 AM, Tim Funk wrote: > Broken pipe means the client the aborted the request which is normal for mp3 > since users probably stop listening to the song early. > > -Tim > > Chris Rolfe wrote: > >> Hi, >> >> My app logs are filled to bursting with stack traces from broken pipes while >> serving embedded mp3 (~100k) files. The files serve ok (status 200), but the >> log clutter is hiding everything else. >> >> Strange thing is these aren't the biggest files. 400k jpg's, etc., no >> problem. The broken pipe exception occurs ONLY on the mp3's. >> >> Any suggestions/clues? >> >> Thanks, >> Chris >> >> Running Tomcat 4.0.4 on an OS X (10.2) setup. >> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DefaultServlet throws a LOT of broken pipe exceptions on mp3s
Hi, My app logs are filled to bursting with stack traces from broken pipes while serving embedded mp3 (~100k) files. The files serve ok (status 200), but the log clutter is hiding everything else. Strange thing is these aren't the biggest files. 400k jpg's, etc., no problem. The broken pipe exception occurs ONLY on the mp3's. Any suggestions/clues? Thanks, Chris Running Tomcat 4.0.4 on an OS X (10.2) setup. -- NB: org.apache.catalina replaced by [*] to avoid wrapping. -- 2003-09-17 10:03:07 StandardWrapperValve[default]: Servlet.service() for servlet default threw exception java.io.IOException: Broken pipe at java.net.SocketOutputStream.socketWrite(Native Method) at java.net.SocketOutputStream.write(SocketOutputStream.java:91) at [*]connector.ResponseBase.flushBuffer(ResponseBase.java:674) at [*]connector.HttpResponseBase.flushBuffer(HttpResponseBase.java:764) at [*]connector.ResponseBase.write(ResponseBase.java:647) at [*]connector.ResponseStream.write(ResponseStream.java:312) at [*]connector.http.HttpResponseStream.write(HttpResponseStream.java:189) at [*]servlets.DefaultServlet.copyRange(DefaultServlet.java:1903) at [*]servlets.DefaultServlet.copy(DefaultServlet.java:1652) at [*]servlets.DefaultServlet.serveResource(DefaultServlet.java:1197) at [*]servlets.DefaultServlet.doGet(DefaultServlet.java:519) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at [*]core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java: 247) at [*]core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at [*]core.StandardWrapperValve.invoke(StandardWrapperValve.java:243) at [*]core.StandardPipeline.invokeNext(StandardPipeline.java:566) at [*]core.StandardPipeline.invoke(StandardPipeline.java:472) at [*]core.ContainerBase.invoke(ContainerBase.java:943) at [*]core.StandardContextValve.invoke(StandardContextValve.java:190) at [*]core.StandardPipeline.invokeNext(StandardPipeline.java:566) at [*]authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:475) at [*]core.StandardPipeline.invokeNext(StandardPipeline.java:564) at [*]valves.CertificatesValve.invoke(CertificatesValve.java:246) at [*]core.StandardPipeline.invokeNext(StandardPipeline.java:564) at [*]core.StandardPipeline.invoke(StandardPipeline.java:472) at [*]core.ContainerBase.invoke(ContainerBase.java:943) at [*]core.StandardContext.invoke(StandardContext.java:2347) at [*]core.StandardHostValve.invoke(StandardHostValve.java:180) at [*]core.StandardPipeline.invokeNext(StandardPipeline.java:566) at [*]valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at [*]core.StandardPipeline.invokeNext(StandardPipeline.java:564) at [*]valves.ErrorReportValve.invoke(ErrorReportValve.java:170) at [*]core.StandardPipeline.invokeNext(StandardPipeline.java:564) at [*]valves.AccessLogValve.invoke(AccessLogValve.java:468) at [*]core.StandardPipeline.invokeNext(StandardPipeline.java:564) at [*]core.StandardPipeline.invoke(StandardPipeline.java:472) at [*]core.ContainerBase.invoke(ContainerBase.java:943) at [*]core.StandardEngineValve.invoke(StandardEngineValve.java:174) at [*]core.StandardPipeline.invokeNext(StandardPipeline.java:566) at [*]core.StandardPipeline.invoke(StandardPipeline.java:472) at [*]core.ContainerBase.invoke(ContainerBase.java:943) at [*]connector.http.HttpProcessor.process(HttpProcessor.java:1027) at [*]connector.http.HttpProcessor.run(HttpProcessor.java:1125) at java.lang.Thread.run(Thread.java:491) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Character Set Issues (windows vs. Unix)
InputStream and OutputStream Readers rely on platform default character
encodings (unless you specify an encoding in the constructor).
For example, a text file with German umlauts encoding in MacRoman translates
without any further effort when read on an OS X server and printed to an
ISO-8859-1 page. Move the text files onto a Windows box, and see the funny
characters.
Perhaps that's the problem?
Cheers,
Chris
on 9/17/03 9:00 AM, Hans Liebenberg at [EMAIL PROTECTED] wrote:
> Hi Anton,
>
> Thats exactly what I am doing. I have even tried
>
> Reader reader = r.getCharacterStream("field_name");
> and then printing out the the char values of the stream same result
>
> Its the most bizarre thing i have seen.
> ...and driving me insane! :(
>
> Thanks for you help
>
> Hans
>
>
>
> -Original Message-
> From: Anton Tagunov [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 16, 2003 9:04 AM
> To: Tomcat Users List; [EMAIL PROTECTED]
> Subject: Re: Character Set Issues (windows vs. Unix)
>
>
> Hello Hans!
>
> HL> When the application is installed on the windows server the particular
> HL> character (which is some kind of spacing character in word) gets read
> out of
> HL> the database as
> HL> Ascii code 160,
>
> HL> BUT on the Linux server the exact same routine reads it as ascii code
> 65533
>
> HL> Same database, same application config - only difference is OS
>
> HL> The JVM's are both set up as default english installs.
>
> Fun story ideed :-)
> Are you sure you get it wron from ResultSet.getString()?
>
> Try doing
>
> String s = rs.getString(x);
> char c = s.charAt(y);
> out.print((int)c);
>
> Are you getting different character codes?
>
> Anton
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Security-constraints - how to forbid all except ...
Hi, Does anyone have a way to set security constraints to forbid access to everything (as the by default) *except* specified files + dirs? The web.xml snippet below comes very close to doing what I want although it relies on the order of constraints (ie, it's container-dependent). The problem with my solution is that incomplete URI's don't have a chance to be redirected to the welcome file. For example, "mydomain.com/myservlet" hit's the SecurityConstraint[Forbidden] before being redirected to index.jsp. So to rephrase the question: Is there a way to set security constraints to forbid access to everything *except* specified files + dirs WITHOUT breaking the site-root welcome-file redirect? Any workaround to exempt the '/' redirect (maybe a servlet-mapping??). Thanks, Chris Tomcat 404 web.xml snippet --- Public /index.jsp /public/* GET POST NONE Forbidden Everything else. /* GET POST PUT DELETE none NONE --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
