RE: Tomcat 5.5.28 on 64 bit windows server 2008.
Hi, > -Original Message- > From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] > Sent: Monday, August 22, 2011 5:35 PM > To: 'Tomcat Users List' > Subject: RE: Tomcat 5.5.28 on 64 bit windows server 2008. > > > > Allow me to clear that up: > 1) If no "address=" parameter is given in the when running > under Windows 2008/Vista/7, then the APR will only bind to the IPv6 > "any" address of [::] for the specified port. > 2) If you need IPv4 support under APR, you will need to either specify > the "address=0.0.0.0" parameter to get the IPv4 "any" address, or > specify the actual IP address to listen on. > 3) If you need to support both IPv4 & IPv6, you will need to set up two > connectors, one for each protocol. > 4) This only applies if you are using the APR/native libraries. > > This was originally discussed on this list in May of 2010, and I think > this was determined to be due to Microsoft deciding to implement two > protocol stacks, but no one was exactly sure. > > Also, this only applies to APR/native version 1.1.12 and later, but I > doubt anyone really wants to use the earlier versions any more. This seems to only apply to Tomcat 5.5.x, however. When Tomcat 7.0.20 and Tomcat 6.0.33 are run on a Windows 2008 machine without editing the config and using the (default) HTTP-APR / AJP-APR connectors, they only bind to the IPv4 "any" address. Only Tomcat 5.5.x binds to the IPv6 address, by default. Maybe 7.0.x and 6.0.x have been changed to use the IPv4 any address by default with the APR connectors, but not 5.5.x. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 5.5.28 on 64 bit windows server 2008.
Hi,
> -Original Message-
> From: Venkata Surapaneni [mailto:vsurapan...@imedx.com]
> Sent: Sunday, August 21, 2011 12:26 PM
> To: Tomcat Users List
> Subject: RE: Tomcat 5.5.28 on 64 bit windows server 2008.
>
> And on top of this all the log look clean. Nothing looks suspicious.
>
> ===
> =
>
> As suggested I have installed the latest version(5.5.33) of Tomcat
> 5.5.x. After installing I have typed in the browser 'http://localhost'
> to check if the tomcat is installed properly. The home page is
> displayed indicating that the installation is fine. Then I typed in ip
> address of the machine 'http://10.4.2.10' and page not found page is
> displayed. This is exactly the same problem why we have downgraded the
> version. There are no changes or customizations made to the
> installation. It was default installation and the only change is to use
> port 80 instead of 8080.
>
> (...)
I see the same behavior when installing Tomcat 5.5.33 (Core) on Windows 7 32
bit. Without changing anything in the config nor other Tomcat files, after
starting Tomcat, http://localhost:8080/ works, whereas
http://192.168.0.4:8080/ (the LAN IP) does not (Connecting to that port
fails). Note that also http://127.0.0.1:8080/ does not work.
>From looking at netstat, it looks like Tomcat is only binding to the IPv6
addresses, but not to IPv4 addresses, so http://127.0.0.1:8080/ can't work.
Netstat's output for the Tomcat process ("ABHÖREN" means "LISTENING"):
TCP[::]:8009 [::]:0 ABHÖREN 3028
TCP[::]:8080 [::]:0 ABHÖREN 3028
The default installation of Tomcat 5.5.33 uses Tomcat Native 1.1.20. After I
remove/rename the tcnative-1.dll in Tomcat's bin directory and restarting
Tomcat, now Tomcat binds also to IPv4 addresses and http://127.0.0.1:8080/
(and the variant with the LAN IP) works.
Netstat:
TCP0.0.0.0:8009 0.0.0.0:0 ABHREN 3596
TCP0.0.0.0:8080 0.0.0.0:0 ABHREN 3596
TCP[::]:8009 [::]:0 ABHREN 3596
TCP[::]:8080 [::]:0 ABHREN 3596
With Tomcat 7.0.20 (using TC Native) and without changing anything in the
config, it seems to only bind to the IPv4 addresses, but no IPv6.
TCP0.0.0.0:8009 0.0.0.0:0 ABHREN 2864
TCP0.0.0.0:8080 0.0.0.0:0 ABHREN 2864
When using Tomcat 7.0.20 (without Native), it binds to IPv4 as well as IPv6
(like Tomcat 5.5.33 without Native).
However I could get TC 5.5.33 to bind on the IPv4 address, by adding the
"address" attribute to the element in server.xml. Maybe you
could try this and see if it solves the problem?
However it seems a bit strange that TC 5.5.33 is only binding to the IPv6
addresses by default/using Native.
Regards,
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
> -Original Message- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Tuesday, July 26, 2011 6:15 PM > To: Tomcat Users List > Subject: Re: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector > 1.2.32 > > You should also null-out the reference to Tomcat's output stream. > > This would allow you to "leak" your own decorator objects but not > interfere with Tomcat's ability to do it's own object management. > > Such a class would definitely be useful to post on the Wiki. > Hi Christopher, thanks for your reply (and sorry for the delay). What would be the best place to post such a class (plus the information about the ImageIO) on the Tomcat Wiki / is there any guide how to write articles there? Thanks! Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
Hi all,
>
> An alternative that I could imagine, would be to create a class (that has
a
> boolean flag) which extends OutputStream, and decorates another
OutputStream
> that is given to the class in the constructor (that would be the
> OutputStream from the servlet's response). This class would pass all calls
> to it to the other OutputStream (as long as the flag is true), and as soon
> as close() or another special method is called, it sets the flag to false,
> which causes all other methods to do nothing (or throw an IOException).
That
> way, Tomcat's OutputStream would also be protected from future calls
> from the ImageIO.
>
I now use a OutputStream decorator like this when calling ImageIO.write():
public class ImageIOBetterOutputStream extends OutputStream {
private OutputStream out; // the actual stream
private volatile boolean isActive = true;
public ImageIOBetterOutputStream (OutputStream out) {
this.out = out;
}
@Override
public void close() throws IOException {
if (isActive) {
isActive = false; // deactivate
try {
out.close();
} finally {
out = null;
}
}
}
@Override
public void flush() throws IOException {
// do nothing
}
@Override
public void write(byte[] b, int off, int len) throws IOException {
if (isActive) {
out.write(b, off, len);
}
}
[...] (overwrite the other methods the same way)
}
That way, I don't have to use a ByteArrayOutputStream to buffer the contents
in memory, and Tomcat's OutputStream is also protected from future calls to
flush() from the ImageIO (I just have to make sure that the call to close()
is inside a finally-block). (If flush() is the only method that the ImageIO
calls after an IOException, it probably would be enough to overwrite flush()
only). Since I'm using this class as OutputStream for the ImageIO, there
also haven't been any more errors.
> I agree that this behavior of the ImageIO is very strange (flushing the
> OutputStream when the ImageWriter gets garbage-collected, if an
IOException
> was thrown when the IIO previously tried to write to the stream).
> However, it seems also a bit strange to me that Tomcat is recycling
OutputStreams,
> because in my understanding, once an OutputStream is closed, it should
> be impossible to do any further write() calls to it.
>
> May I ask, what is the particular reason for Tomcat to recycle
> OutputStreams?
Does anyone have a clue about this? I can understand recycling objects like
the Request/Response objects (e.g. if they contain lots of fields), but at
the moment I don't have an idea why it would be useful to recycle
OutputStream objects.
> Also, is there any hint to this on the Tomcat documentation/wiki? Because
I
> don't think it would be unusual to dynamically generate images and
> serve them to clients using the ImageIO, and I think it could be a bit
> frustrating to find the actual problem if one doesn't know this.
I couldn't find any hints about this in the Tomcat documentation/wiki, but I
think it should be mentioned somewhere. Of course, the behavior of the
ImageIO is strange, but Tomcat's recycling of OutputStreams enable the
errors when using the ImageIO.
If it is desired, maybe I could contribute something to this topic for
docs/wiki?
Regards,
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to send binary data in a form field via Java
Hi,
> -Original Message-
> From: Paritosh Patel [mailto:xygnu...@gmail.com]
> Sent: Friday, July 15, 2011 5:24 PM
> To: users@tomcat.apache.org
> Subject: How to send binary data in a form field via Java
>
> I apologize in advance if this is not the correct mail list for such a
> question, but this is the closest one I could find.
>
> (I am using Tomcat 6.0.26 but my question is generic in nature)
>
> I have a Java client that talks to a servlet using several text fields.
> I now wanted to add a field that includes binary data (in this case a
> protocol buffer byte array). The data gets to the servlet, but the
> bytes are changed. Specifically, it appears that the encoding/decoding
> of bytes > 127 are not the same as the original bytes.
That's expected, because ASCII is only defined to byte 127. From byte 128,
the related characters differ by the used Encoding (UTF-8, ISO-8859-1,...)
>
> The client specified content-type to be "application/x-www-form-
> urlencoded" right now, but I have tried several others. Then, for
> encoding, I have tried encoding the bytes using URLEncoder
>
> ByteArrayOutputStream osBytes = new ByteArrayOutputStream();
> byte[] val = "..." // My binary data
> String valStr = new String((byte[]) val);
> osBytes.write(URLEncoder.encode(valStr, "UTF-8").getBytes());
That is unreliable, because the bytes are converted to chars using the
platform's default charset. If that differs from the server's one, the bytes
will be decoded to other characters.
Have you tried to just Hex-encode the bytes when sending it to the server,
and decoding it on the server side? For example, if your byte[] array is {1,
99, 0, 255}, you could encode it to the hex string "016300FF", and then on
the server side, decode it to bytes.
However, a more efficient form would be to encode the bytes via Base64,
which will mean a increase in size of only 33% instead 100% (when
hex-encoding it).
Regards,
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
Hi André, > -Original Message- > From: André Warnier [mailto:a...@ice-sa.com] > Sent: Thursday, July 14, 2011 1:00 PM > To: Tomcat Users List > Subject: Re: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector > 1.2.32 > > As a comment purely from a general programming point of view, not a > Java/Tomcat > programming point of view : > > I am not familiar with the ByteArrayOutputStream, but from your usage > of it above it seems > to be a buffer in memory to which one can write, and with a special > "writeTo" method which > must be an efficient way to copy its contents to another stream. > > If so, whether it is good practice or not would depend entirely on your > particular > circumstances : the size of the images you are handling this way, the > number of > simultaneous requests which you are handling, how much memory you have > to play with, and > how fast your CPU is. > It is sometimes surprising to make the calculation. > > (...) > > So, compared to using the Response output stream directly, you would > now use an additional > (375 KB X 400) = 150,000 KB = about 150 MB additional Heap space > > That seems reasonable to me. > But of course it would be a problem if you are currently running Tomcat > with a 128 MB heap. > Or if your images, instead of being 250 KB on average, would be 250 MB. > Or if filling up - and reading back - the ByteArrayOutputStream was > very inefficient and > used up all your CPU time. > > On the other hand, the alternative is to have broken responses, so it > may be better to add > some RAM to the system. > Thanks for your long response. Your assumption about ByteArrayOutputStream is correct: It buffers the contents written to it in a byte array, which automatically grows if its capacity is exceeded, by factor 2. However I think the memory is not a big issue here, because the data that is written to the ByteArrayOutputStream is the compressed version of an image that is already in RAM, and that is usually much bigger than the compressed form. For example, when I have a BufferedImage of 800x600 pixel and 24 bit per pixel (TYPE_INT_RGB), it consumes 800*600*3 bytes = 1,37 MiB in memory. The size of the compressed form varies from file type (JPEG, PNG, ...) and the contents of the image, but if I would save it as JPEG for example, it will only take about 200 KiB, which is much less than the uncompressed form in the memory. An alternative that I could imagine, would be to create a class (that has a boolean flag) which extends OutputStream, and decorates another OutputStream that is given to the class in the constructor (that would be the OutputStream from the servlet's response). This class would pass all calls to it to the other OutputStream (as long as the flag is true), and as soon as close() or another special method is called, it sets the flag to false, which causes all other methods to do nothing (or throw an IOException). That way, Tomcat's OutputStream would also be protected from future calls from the ImageIO. I agree that this behavior of the ImageIO is very strange (flushing the OutputStream when the ImageWriter gets garbage-collected, if an IOException was thrown when the IIO previously tried to write to the stream). However, it seems also a bit strange to me that Tomcat is recycling OutputStreams, because in my understanding, once an OutputStream is closed, it should be impossible to do any further write() calls to it. May I ask, what is the particular reason for Tomcat to recycle OutputStreams? Thanks! Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
Hi Rainer, > -Original Message- > From: Rainer Jung [mailto:rainer.j...@kippdata.de] > Sent: Thursday, July 14, 2011 12:17 AM > At least there was trouble about Java2D for several users in the past. > One such issue: > > https://issues.apache.org/bugzilla/show_bug.cgi?id=41772 > http://nerd.dk/blogs/bug-tomcat-or-java2d > > but you might find more. > > Regards, > > Rainer > Thanks. In the meantime, I also came to that conclusion and replaced all instances of ImageIO.write(img, "PNG", response.getOutputStream()) in my servlets/webapps with something like ByteArrayOutputStream bout = new ByteArrayOutputStream(); ImageIO.write(img, "PNG", bout); bout.writeTo(response.getOutputStream()); so that the ImageIO never sees the real OutputStream, and it seems to work fine (no more IllegalStateExceptions or "wrong message format" errors in the isapi log when using AJP-APR). Is that a good practice (using ByteArrayOutputStream, then copy it to the response) to dynamically generate Images and serve them to the clients? Also, is there any hint to this on the Tomcat documentation/wiki? Because I don't think it would be unusual to dynamically generate images and serve them to clients using the ImageIO, and I think it could be a bit frustrating to find the actual problem if one doesn't know this. Thanks! Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
Hi André, > -Original Message- > From: André Warnier [mailto:a...@ice-sa.com] > Sent: Tuesday, July 12, 2011 9:25 PM > > Can you take a part of this setup out of the equation ? > > For example, at the moment you have > > browser <-> IIS <-> isapi_redir. <-> AJP Connector:8019 <-> > Tomcat+webapp > > Could you eliminate the IIS + Isapi_redir part, having Tomcat listen on > port 80/HTTP, like > this : > > browser <-> HTTP Connector:80 <-> Tomcat+webapp > > ? > > or like this, by using Apache httpd instead of IIS : > > browser <-> Apache <-> mod_jk <-> AJP Connector:8019 <-> Tomcat+webapp > > This may help pinpointing where the problem is, since you mentioned > earlier that you can > reproduce the problem by pressing F5 in Firefox. > Unfortunately, I can't replace IIS with Apache or direct Tomcat HTTP connector, as that webapp is on a public server where also other websites are hosted, using IIS. But perhaps I can see if I can reproduce the problem in a virtual machine. Please note that I could only reproduce the problems that occurred before switching from AJP-APR to AJP-BIO. There I could reproduce them by pressing and holding F5 in Firefox for some seconds, but after I switched to AJP-BIO, that didn't worked. The error message I wrote in the last mail did I see when I read the isapi logs today. Today I also got another strange exception in Tomcat (I don't know if it has anything to do with the AJP errors): 13.07.2011 00:13:51 org.apache.catalina.core.StandardWrapperValve invoke SCHWERWIEGEND: Servlet.service() for servlet [hauptSeite.HauptServlet] in context with path [] threw exception java.lang.IllegalStateException: Cannot create a session after the response has been committed at org.apache.catalina.connector.Request.doGetSession(Request.java:2734) at org.apache.catalina.connector.Request.getSession(Request.java:2244) at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:89 9) at common.Common2.getSession(Common2.java:102) at hauptSeite.HauptServlet.doThings(HauptServlet.java:136) at hauptSeite.HauptServlet.doGet(HauptServlet.java:98) at javax.servlet.http.HttpServlet.service(HttpServlet.java:621) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:304) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:240) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:164) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase .java:462) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164 ) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100 ) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :118) at org.apache.catalina.valves.CrawlerSessionManagerValve.invoke(CrawlerSessionM anagerValve.java:172) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:403) at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:292) at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.j ava:143) at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.j ava:129) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java: 309) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja va:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9 08) at java.lang.Thread.run(Thread.java:662) This appeared some minutes ago. I also have seen this Exception some times on JSP pages, but not on a normal Servlet (for JSP pages, the stack trace contained "at org.apache.jasper.runtime.JspFactoryImpl.getPageContext(JspFactoryImpl.java: 65)" and that was before any custom JSP code). This above error is from a WebApp that I use for hosting images. The stack trace seems to indicate that a response has been committed before a session is created, however I absolutely never send any response before creating a session in that Servlet (I call response.getWriter() or response.getOutputStream several lines after I call request.getSession(true) ). Hmm, could it be that the Java ImageIO is re-using OutputStreams after calling ImageIO.write(img, "PNG", out), so that I'm getting such a IllegalStateException? (I think I read somewhere that Tomcat is recycling OutputStream objects) Maybe that could also explain the AJP errors I got. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For addi
RE: AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
> > However, when I switch to AJP BIO, it seems that the errors go away. > Although I now switched to AJP-BIO (by deleting/renaming tcnative-1.dll), today morning I got an error again in the ISAPI log: [Tue Jul 12 06:04:49.812 2011] [4124:2444] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (1296): wrong message format 0xdaed from 127.0.0.1:8019 [Tue Jul 12 06:04:49.825 2011] [4124:2444] [error] ajp_get_reply::jk_ajp_common.c (2148): (worker1) Tomcat is down or network problems. Part of the response has already been sent to the client This is how the AJP connector is configured in Tomcat: Any idea what could cause this errors? I don't know it that matters, but with one webapp, I'm using COM4J to access COM objects on the Windows system (but I want to get rid of it in the future). Thanks, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AJP-APR failures on Tomcat 7.0.16 with ISAPI Redirector 1.2.32
Hi all, I have a system with Windows Server 2008 (32 bit), Sun/Oracle JDK 1.6.0_26 and Im using Tomcat 7.0.16 with Tomcat Native 1.1.20, and IIS 7.0 with ISAPI Redirector 1.2.32. For AJP, I use the AJP-APR connector. Sometimes, when many requests are sent to a webapp in short time, some requests fail, and the ISAPI log (log_level=error) says: [Sun Jul 10 21:35:55.061 2011] [580:5032] [error] ajp_get_reply::jk_ajp_common.c (2187): (worker1) Tomcat already send headers [Sun Jul 10 21:35:55.071 2011] [580:5032] [error] ajp_service::jk_ajp_common.c (2600): (worker1) sending request to tomcat failed (unrecoverable), (attempt=1) [Sun Jul 10 21:35:55.080 2011] [580:5032] [error] HttpExtensionProc::jk_isapi_plugin.c (2261): service() failed with http error 502 [Sun Jul 10 21:35:55.087 2011] [580:4776] [error] ajp_get_reply::jk_ajp_common.c (2187): (worker1) Tomcat already send headers [Sun Jul 10 21:35:55.097 2011] [580:4776] [error] ajp_service::jk_ajp_common.c (2600): (worker1) sending request to tomcat failed (unrecoverable), (attempt=1) [Sun Jul 10 21:35:55.104 2011] [580:4776] [error] HttpExtensionProc::jk_isapi_plugin.c (2261): service() failed with http error 502 [Sun Jul 10 21:37:20.662 2011] [5696:3220] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (1296): wrong message format 0x3000 from 127.0.0.1:8019 [Sun Jul 10 21:37:20.679 2011] [5696:3220] [error] ajp_get_reply::jk_ajp_common.c (2118): (worker1) Tomcat is down or refused connection. No response has been sent to the client (yet) [Sun Jul 10 21:42:56.105 2011] [580:5032] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (1296): wrong message format 0x3000 from 127.0.0.1:8019 [Sun Jul 10 21:42:56.135 2011] [580:5032] [error] ajp_get_reply::jk_ajp_common.c (2118): (worker1) Tomcat is down or refused connection. No response has been sent to the client (yet) [Sun Jul 10 21:42:56.149 2011] [580:3100] [error] ajp_get_reply::jk_ajp_common.c (2187): (worker1) Tomcat already send headers [Sun Jul 10 21:42:56.160 2011] [580:3100] [error] ajp_service::jk_ajp_common.c (2600): (worker1) sending request to tomcat failed (unrecoverable), (attempt=1) [Sun Jul 10 21:42:56.168 2011] [580:3100] [error] HttpExtensionProc::jk_isapi_plugin.c (2261): service() failed with http error 502 [Sun Jul 10 21:45:49.849 2011] [580:4532] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (1296): wrong message format 0x3000 from 127.0.0.1:8019 [Sun Jul 10 21:45:49.867 2011] [580:4532] [error] ajp_get_reply::jk_ajp_common.c (2118): (worker1) Tomcat is down or refused connection. No response has been sent to the client (yet) However I didn't see any errors in the Tomcat logs. I could reproduce the errors by pressing F5 in Firefox several seconds, so that FF makes a lot of requests in a short time. However, when I switch to AJP BIO, it seems that the errors go away. Please note that I'm also using the Java ImageIO to produce and serve images with some servlets. I think somewhere I read that using the ImageIO with APR connectors could cause problems. Is this correct? If yes, does that mean that I have to stick with the AJP BIO (or NIO?) connector, instead of AJP APR; or does anybody know why there are these errors? Thanks. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: NPE at StandardWrapperValve.invoke() in Tomcat 7.0.16
Hi Christopher, > > The compiler must have gotten smarter than the last time I checked. > I'm sorry: I compiled that code with the Eclipse compiler. When compiling it with the Oracle Java compiler (javac), it prints out the line number of the "System.out.println". Maybe if Tomcat was compiled with the standard Java compiler, it could be that on the NPE at StandardWrapperValve.invoke(), also "context" was null, like in the NPE at StandardContextValve.invoke(). > > You could modify the source and add another dump of the original > exception (say, to stdout). That way, if it does happen again, you'll > at > least see the root cause. > OK, I may try that. But I have never seen that NPE in StandardWrapperValve before I started this thread, so I don't think it is worth it (Tomcat 7 releases are every month, and I don't want to modify the code in each version). :) > > No, it sounds like that might be a rarely-seen bug in Tomcat since it > happens only during context reload while a long-running request is in > progress. If you can build a simple test case, attach it to a new BZ > entry and we'll see about getting it fixed. > OK, Thanks. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: NPE at StandardWrapperValve.invoke() in Tomcat 7.0.16
Hi Christopher, > > My experience with the Sun/Oracle compiler is that lines 288 and 289 > will never be indicated in a stack trace: the line number of the start > of the statement is considered the line number for the entire > statement. Well, I made a small test program with this code: String str = null; System.out.println( "blah" + str.toLowerCase() ); (note that the str.toLowerCase() which will throw a NPE is two lines below the System.out.println() call). After compiling and running it with the Oracle Java 1.6.0_26, the line number printed was the line with the "str.toLowerCase()", not the "System.out.println". So I assume the same is true for the compiled Tomcat, thus I supposed that only container or the logger could be null). > > Problem solved? > Well, I don't know what the original problem was, so I don't know if it is solved. ;) My concern at the moment is not the original exception that occurred, but the NPE that suppressed that exception, because if it happens again, I will not able to see what was the original exception. As Pid said, it could have something to do with the old context which was still waiting for a request to finish, and as I stated in the other message, I could reproduce a NPE, but in StandardContextValve.invoke() (there "context" was null). But NPEs thrown are never good, are they? Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: NPE at StandardWrapperValve.invoke() in Tomcat 7.0.16
> Maybe I can reproduce the
> NPE if I make a servlet that takes a long time to finish the request,
> to see what was the original exception that has been suppressed by the
> NPE.
OK, I was able to reproduce a NPE in TC 7.0.16 with a Servlet that calls
"Thread.sleep(2)", then make a request to that servlet and immediately
redeploy that webapp. However, this time the NPE was not in
StandardWrapperValve.invoke(), but in StandardContextValve.invoke():
08.07.2011 00:26:40 org.apache.catalina.connector.CoyoteAdapter service
SCHWERWIEGEND: An exception or error occurred in the container during the
request processing
java.lang.NullPointerException
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:403)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:301)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:162)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:140)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:309)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The lines around 172 in StandardContextValve are these:
166 // If the request was async at the start and an error occurred then
167 // the async error handling will kick-in and that will fire the
168 // request destroyed event *after* the error handling has taken
169 // place
170 if (!(request.isAsync() || (asyncAtStart && request.getAttribute(
171 RequestDispatcher.ERROR_EXCEPTION) != null))) {
172 context.fireRequestDestroyEvent(request);
173 }
The problem here is that "context" is null (I debugged TC in Eclipse). However,
this time it seems that it is not another Exception that has been suppressed by
a NPE.
I checked that the NPE in StandardContextValve.invoke() also occurs in Tomcat
7.0.18.
Unfortunately, I was not able to reproduce the NPE in
StandardWrapperValve.invoke().
Regards,
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: NPE at StandardWrapperValve.invoke() in Tomcat 7.0.16
Hi Pid,
> -Original Message-
> From: Pid [mailto:p...@pidster.com]
> Sent: Thursday, July 07, 2011 10:24 PM
>
> Are you using parallel deployment or are you replacing the existing
> application when it's redeployed.
>
> Maybe the old context is the one throwing the error.
>
>
> p
I don't use parallel deployment.
To redeploy a webapp, I just replace the old war file with a new one and wait
for Tomcat to redeploy it.
The logs on redeploy were this:
07.07.2011 00:24:09 org.apache.catalina.startup.HostConfig checkResources
INFO: Undeploying context []
07.07.2011 00:24:09 org.apache.catalina.core.StandardWrapper unload
INFO: Waiting for 1 instance(s) to be deallocated
07.07.2011 00:24:10 org.apache.catalina.core.StandardWrapper unload
INFO: Waiting for 1 instance(s) to be deallocated
07.07.2011 00:24:11 org.apache.catalina.core.StandardWrapper unload
INFO: Waiting for 1 instance(s) to be deallocated
07.07.2011 00:24:12 org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SCHWERWIEGEND: The web application [] is still processing a request that has
yet to finish. This is very likely to create a memory leak. You can control the
time allowed for requests to finish by using the unloadDelay attribute of the
standard Context implementation.
07.07.2011 00:24:12 org.apache.catalina.startup.ExpandWar deleteDir
SCHWERWIEGEND: [D:\tomcat7\work\Catalina\bildergalerie.pleier-it.de\_] could
not be completely deleted. The presence of the remaining files may cause
problems
07.07.2011 00:24:12 org.apache.catalina.startup.ExpandWar delete
SCHWERWIEGEND: [D:\tomcat7\work\Catalina\bildergalerie.pleier-it.de\_] could
not be completely deleted. The presence of the remaining files may cause
problems
07.07.2011 00:24:12 org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive ROOT.war
07.07.2011 00:24:17 org.apache.catalina.connector.CoyoteAdapter service
SCHWERWIEGEND: An exception or error occurred in the container during the
request processing
java.lang.NullPointerException
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:287)
...
("SCHWERWIEGEND" should read like "SEVERE")
You're right, it could have something to do with the old context since it was
still waiting for a request to finish. Maybe I can reproduce the NPE if I make
a servlet that takes a long time to finish the request, to see what was the
original exception that has been suppressed by the NPE.
Regards,
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: NPE at StandardWrapperValve.invoke() in Tomcat 7.0.16
Hi Christopher, > -Original Message- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Thursday, July 07, 2011 9:13 PM > > Looks like it. I would be very interested to know which of those > objects > is null: the container, the logger, the wrapper, or the context. > > - -chris I thought the same (I suppose only container or the logger can be null, according to the stacktrace, because if the wrapper or the context were null, it should have printed a different line number). Unfortunately, I don't see this NPE anymore so I can't use a modified Tomcat to debug it. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: NPE at StandardWrapperValve.invoke() in Tomcat 7.0.16
Hi Pid, > -Original Message- > From: Pid [mailto:p...@pidster.com] > Sent: Thursday, July 07, 2011 6:19 PM > > What is the request for and is the config of your Tomcat instance > modified from the original download - if so, what has changed (config > etc)? > > > p > I don't know which request triggered that NPE. I guess it was on the first request after deploying the webapp, all following requests worked fine. I got that NPE 2 times, both times it appeared ca. 3 seconds after deploying the webapp. After I restarted Tomcat, the NPE didn't appear anymore. My Tomcat config has the following changes compared to the original: - Ports of the HTTP and AJP connector are changed - I use the "URIEncoding" attribute on both the HTTP and AJP connector, like this: - I declared the CrawlerSessionManagerValve at Engine level in server.xml: - I have several virual hosts declared in server.xml like this: some_alias (the web application on which the error occurred was deployed to one of the virtual hosts). - I don't have any AccessLogValve declared. - I disabled session persistence by adding in context.xml. I am using the ISAPI Redirector 1.2.32 with IIS 7.0 on Windows Server 2008 (32 bit), with Sun Java 1.6.0_26, and I'm using the Tomcat Native library 1.2.20. All requests to the webapps go through the ISAPI redirector. It seems to me that originally another Exception occurred, but has been suppressed by that NPE when Tomcat tried to log it. Thanks for your answers. Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
NPE at StandardWrapperValve.invoke() in Tomcat 7.0.16
Hi all,
Im using Tomcat 7.0.16 on a system with Java 1.6.0_26 on Windows Serer 2008
and wondered about a strange NPE I got shortly after deploying a webapp to
Tomcat:
SCHWERWIEGEND: An exception or error occurred in the container during the
request processing
java.lang.NullPointerException
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:287)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:164)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase
.java:462)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164
)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100
)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:118)
at
org.apache.catalina.valves.CrawlerSessionManagerValve.invoke(CrawlerSessionM
anagerValve.java:172)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:403)
at
org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:284)
at
org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProt
ocol.java:146)
at
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:
1730)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
va:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
08)
at java.lang.Thread.run(Thread.java:662)
>From looking at Tomcat 7.0.16's source, I can see that line 287 in
StandardWrapperValve is inside a catch block:
285 } catch (Throwable e) {
286 ExceptionUtils.handleThrowable(e);
287 container.getLogger().error(sm.getString(
288 "standardWrapper.serviceException", wrapper.getName(),
289 context.getName()), e);
290 throwable = e;
291 exception(request, response, e);
292 }
So does that mean that another Exception/Error occurred, but was suppressed
by that NPE and therefore couldn't be logged?
Regards,
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Multiple errors (regressions) on Tomcat 7.0.17
Hi Mark, > If you explicitly set crawlerUserAgents, that will be resolved. Thanks. > > > 2) When using the ISAPI Redirector 1.2.32 and Tomcat Native 1.1.20 > which is > > included in the windows distribution, I get these errors when a > client makes > > a request to IIS which is redirected to Tomcat, resulting in 100% CPU > usage > > by tomcat's process: > > Under what circumstances? Some requests, all requests? The APR/native > AJP connector works with mod_jk and mod_proxy_ajp on linux so it looks > like either the ISAPI redirector is sending something unexpected that > isn't handled well or the windows specific code in the APR/native > connector isn't handling something. For this test, I downloaded the Tomcat 7.0.17 (windows 64 bit) and extracted it to a directory. I didn't changed anything in the Tomcat directory (also not the config files). I set the ISAPI Redirector 1.2.32 to redirect all requests to Tomcat on port 8009, using ajp13. I made this exact request multiple times to IIS: GET / HTTP/1.1 Host: localhost Connection: keep-alive This should be handled by the default Tomcat root webapp (which displays the Tomcat welcome page). The first 2-4 requests work (the number is not always the same), but then on the next request, Tomcat CPU usage goes up to 100% and the client never receives a response (then Tomcat displays the error "Critical poller failure" some multiple times). 03.07.2011 16:03:49 org.apache.tomcat.util.net.AprEndpoint$Poller run SCHWERWIEGEND: Critical poller failure (restarting poller): [610038] APR does not understand this error code In the isapi log, following lines appear (log_level=info): [Sun Jul 03 15:54:44.530 2011] [2908:2664] [info] init_jk::jk_isapi_plugin.c (2602): Starting Jakarta/ISAPI/isapi_redirector/1.2.32 () [Sun Jul 03 15:54:44.546 2011] [2908:2664] [info] init_jk::jk_isapi_plugin.c (2781): Jakarta/ISAPI/isapi_redirector/1.2.32 () initialized [Sun Jul 03 15:54:46.327 2011] [2908:1968] [error] ajp_connection_tcp_get_message::jk_ajp_common.c (1296): wrong message format 0x from 127.0.0.1:8009 [Sun Jul 03 15:54:46.452 2011] [2908:1968] [error] ajp_get_reply::jk_ajp_common.c (2118): (worker1) Tomcat is down or refused connection. No response has been sent to the client (yet) [Sun Jul 03 15:54:46.452 2011] [2908:1968] [info] ajp_service::jk_ajp_common.c (2607): (worker1) sending request to tomcat failed (recoverable), because of protocol error (attempt=1) After this occurs, Tomcat doesn't respond to subsequent requests (sent via IIS). Then, on shutdown, Tomcat prints: 03.07.2011 16:07:27 org.apache.catalina.core.StandardServer await INFO: A valid shutdown command was received via the shutdown port. Stopping the Server instance. 03.07.2011 16:07:27 org.apache.coyote.AbstractProtocol pause INFO: Pausing ProtocolHandler [http-apr-8080] 03.07.2011 16:07:28 org.apache.coyote.AbstractProtocol pause INFO: Pausing ProtocolHandler [ajp-apr-8009] 03.07.2011 16:07:29 org.apache.catalina.core.StandardService stopInternal INFO: Stopping service Catalina 03.07.2011 16:07:29 org.apache.coyote.AbstractProtocol stop INFO: Stopping ProtocolHandler [http-apr-8080] After those lines are printed, it takes some time, then these lines are printed (a new line is printed every second until I kill the tomcat process): WARNUNG: Acceptor thread [http-apr-8080-Acceptor-0] failed to unlock. Forcing hard socket shutdown. 03.07.2011 16:08:30 org.apache.tomcat.util.net.AprEndpoint stopInternal WARNUNG: Acceptor thread [http-apr-8080-Acceptor-0] failed to unlock. Forcing hard socket shutdown. 03.07.2011 16:08:31 org.apache.tomcat.util.net.AprEndpoint stopInternal WARNUNG: Acceptor thread [http-apr-8080-Acceptor-0] failed to unlock. Forcing hard socket shutdown. 03.07.2011 16:08:32 org.apache.tomcat.util.net.AprEndpoint stopInternal WARNUNG: Acceptor thread [http-apr-8080-Acceptor-0] failed to unlock. Forcing hard socket shutdown. When I delete the Tomcat 7.0.17 and download the regular 7.0.16 (and extract it to the same directory, and don't change any of the Tomcat files), it works fine. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Multiple errors (regressions) on Tomcat 7.0.17
Hi all, today I downloaded the not yet released Tomcat 7.0.17 (downloaded it from http://people.apache.org/~markt/dev/tomcat-7/v7.0.17/bin/ ) to test it on a Windows Server 2008 R2 (64 bit) system with Sun Java 1.6.0_26 (64 bit), using IIS 7.5 and the ISAPI Redirector 1.2.32 (from http://people.apache.org/~mturk/tomcat-connectors/jk/binaries/windows/ ). I used the 64 bit versions of Tomcat and the ISAPI redirector. I noticed some regressions which do not occur when using Tomcat 7.0.16 instead. 1) When declaring the CrawlerSessionManagerValve at Engine level in server.xml: then I get a NPE when a client makes a request to Tomcat (or to IIS, which is redirected to Tomcat by the ISAPI redirector): 03.07.2011 01:24:08 org.apache.catalina.connector.CoyoteAdapter service SCHWERWIEGEND: An exception or error occurred in the container during the request processing java.lang.NullPointerException at org.apache.catalina.valves.CrawlerSessionManagerValve.invoke(CrawlerSessionM anagerValve.java:147) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:404) at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:197) at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProt ocol.java:152) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java: 1731) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja va:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9 08) at java.lang.Thread.run(Thread.java:662) This is because the uaPattern field in CrawlerSessionManagerValve is null. With Tomcat 7.0.16, it works fine. 2) When using the ISAPI Redirector 1.2.32 and Tomcat Native 1.1.20 which is included in the windows distribution, I get these errors when a client makes a request to IIS which is redirected to Tomcat, resulting in 100% CPU usage by tomcat's process: 03.07.2011 01:26:29 org.apache.tomcat.util.net.AprEndpoint$Poller run SCHWERWIEGEND: Critical poller failure (restarting poller): [610038] APR does not understand this error code Sometimes, the entire Tomcat process crashes with an EXCEPTION_ACCESS_VIOLATION in tcnative-1.dll: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x1001f43a, pid=2260, tid=232 # # JRE version: 6.0_26-b03 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode windows-amd64 compressed oops) # Problematic frame: # C [tcnative-1.dll+0x1f43a] # Also, this works fine with Tomcat 7.0.16 (also when using the included Tomcat Native 1.1.20 and the ISAPI redirector 1.2.32): no crashes or "critical poller failure" messages. Please note that the errors also occur on a 32 bit Windows Server 2008 system. These do not seem to occur with the HTTP APR connector. Also, when using the AJP BIO instead of AJP APR, they don't occur. I didn't see any reports for this on the dev list, so I thought I post them here. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Canceling Download on IIS7 with ISAPI Redirector 1.2.31 causes 100% CPU usage
Hi André, thanks for your reply. > To figure out if this is what's happening, you could do some logging at > the servlet end, > to see if it keeps sending data even when the client has canceled, or > if it itself gets > some stop indication from the isapi_redirector (also a closed socket > e.g.). > > Or else Mladen or Rainer could tell us if I'm totally off-base here. I added some logging to the Servlet to see what it is actually doing (logging the start and end of the doGet() method and every time 2 MB are written, and I also put the write loop in a try-catch clause to catch IOException). You are right: When I start the download, the servlet writes the bytes slowly (due to the speed of the Connection) to the output. However, when I then cancel the download, it writes the remaining bytes very fast, probably causing the high CPU usage of the ISAPI redirector. But in some cases, the result is another: After I canceled the download, the write() method throws an IOException: ClientAbortException: java.io.IOException: Failed to send AJP message and the remaining bytes are not written, so the CPU usage does not go up to 100% (That's probably the other case I mentioned before, that sometimes the CPU usage doesn't go up). However I would expect write() to always throw an IOException when the connection to the client is aborted, but it seems that in most cases, the IOException is not thrown, thus causing the servlet to write the remaining bytes very fast to the ISAPI redirector and probably causing the high CPU load. Do you or anybody have an idea why sometimes the IOException is not thrown when the Client aborts the Connection? Cheers Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Canceling Download on IIS7 with ISAPI Redirector 1.2.31 causes 100% CPU usage
Hello everybody,
I stumbled upon a strange problem with the ISAPI Redirector 1.2.31 on
Windows Server 2008 SP2 (32 bit) with IIS 7.0. The problem is, that when a
Servlet is generating lots of data (e.g. 200 MB) and a user downloads it
over the Isapi Redirector/IIS7, and cancels the download, the IIS Worker
process (w3wp.exe) will have 100% CPU usage for about 30 seconds. However if
the download is completed normally (not canceled), everything is fine and
the CPU usage will not go up that far.
The exact Components used are:
Windows Server 2008 SP2 (32 bit) with IIS 7.0,
Sun JDK 1.6.0_25,
Tomcat 7.0.14,
ISAPI Redirector 1.2.31.
I could reproduce the problem with a clean install of these components.
To reproduce:
1. Install Tomcat and the ISAPI Redirector on a Windows Server 2008 SP2 IIS
7.0 system, as described in the Tomcat Connectors Documentation
(The problem occurs with both settings of "enable_chunked_encoding", "true"
and "false").
2. Create a Servlet or JSP that produces some huge amount of random data,
for example:
@WebServlet("/DownloadServlet")
public class DownloadServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
response.setContentType("application/x-msdownload");
OutputStream out = response.getOutputStream();
Random r = new Random();
byte[] content = new byte[1024];
for (int i = 0; i < content.length; i++)
content[i] = (byte) (r.nextFloat() * 256);
for (int i = 0; i < 20; i++)
out.write(content);
out.close();
}
}
3. Request the Servlet or JSP through the IIS port with a browser. After
some seconds, cancel the download.
4. One thread of the IIS Worker Process (w3wp.exe) will have 100% CPU usage
for some time (about 30 seconds), before it normalizes to 0%.
Note that is does not happen every time. Sometimes you will have to repeat
starting and canceling the download until the problem occurs.
5. In the ISAPI log, following lines are logged ("log_level"="info"):
[Sat May 14 14:48:55.654 2011] [3508:3560] [error]
isapi_write_client::jk_isapi_plugin.c (1210): WriteClient failed with 995
(0x03e3)
[Sat May 14 14:48:55.654 2011] [3508:3560] [info]
ajp_process_callback::jk_ajp_common.c (1885): Writing to client aborted or
client network problems
[Sat May 14 14:48:55.654 2011] [3508:3560] [info]
ajp_service::jk_ajp_common.c (2543): (worker1) sending request to tomcat
failed (unrecoverable), because of client write error (attempt=1)
[Sat May 14 14:48:55.669 2011] [3508:3560] [info]
HttpExtensionProc::jk_isapi_plugin.c (2217): service() failed because client
aborted connection
These lines are logged immediately after the client cancels the connection
(not after the CPU usage of w3wp.exe goes down).
The worker process continues normally after the CPU usage went down.
However, if one would do this repeatedly, it could enable DoS attacks,
couldn't it?
What would cause these excessive CPU usages of the IIS worker process when
the user cancels the download?
Thanks for your help.
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
NPE instead of '400 Bad Request' response when sending invalid request on Tomcat 7.0.7
Hi all, I noticed that when sending an invalid request to Tomcat 7.0.7 (e.g. without a HTTP method), Tomcat throws a NullPointerException, instead of responding with a "400 Bad Request". If you do a request like this for example: /invalidRequest HTTP/1.1 Host: localhost Then Tomcat prints: 04.02.2011 02:16:44 org.apache.catalina.connector.CoyoteAdapter service SCHWERWIEGEND: An exception or error occurred in the container during the request processing java.lang.NullPointerException at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:409) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:243) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http 11Protocol.java:188) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http 11Protocol.java:166) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java: 288) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) and closes the connection without sending a response. Shouldn't Tomcat respond with "400 Bad Request" instead of throwing a NPE? ;) (I don't think this is a big issue, just wanted to note that behavior.) Cheers Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: No response buffering in Tomcat 7.0.6?
Hi everybody, thanks for your replies. > -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > > Chunked encoding does not mean that the output is unbuffered. If a > client declares support for HTTP/1.1 then web servers are free to use > chunked encoding for the response if they choose. Hi Mark, you're right: It seems Tomcat actually uses a buffer for the response. But it seems a bit strange to me that it uses chunked encoding, although the content length should be known when sending the headers as the response fits into the buffer. I agree that Tomcat itself is not violating the spec. However what is not compliant to the spec, are that 304 responses that I get from IIS when using the ISAPI redirector 1.2.31 (with chunked encoding enabled) with Tomcat 7.0.6 (and this time for normal 304 responses, not the ones from bug #50413 ;) ), because they contain a "Transfer-encoding: chunked" header and a body (as described in bug #50363). This worked fine with Tomcat 7.0.5. I will have to disable the chunked encoding support in the ISAPI redirector in order to get spec-compliant 304 responses (because then they will have a "Connection: close" header without a body) until the 1.2.32 connectors are released. > -Original Message- > From: André Warnier [mailto:a...@ice-sa.com] > > There have a been another couple of threads recently related to the > chunked transfer-encoding. > If I remember correctly, in one of them the OP complained about Tomcat > using this encoding > for small responses, on the grounds of the added overhead or bandwidth > introduced by the > chunk headers. > I am not sure that I agree with the basic principle (as the transfer- > encoding is really > the server's or intermediate agent's decision), but say in the interest > of keeping the peace : Hello André, Well I do not want to disable chunked encoding. I clearly prefer a "Transfer-encoding: chunked" header over a "Connection: close" header when the content length is not known in advance, because with chunked encoding the connection can stay open, whereas with a "Connection: close" the connection has to be closed after the response is finished. That's why I want to use the ISAPI redirector with chunked encoding enabled; however this regression is preventing me from doing this, as it would cause invalid 304 responses (and I can't compile the trunk version of the Connectors by myself, so I have to wait until 1.2.32 gets released or the regression in Tomcat is fixed). Again, thanks for your replies. Cheers Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
