RE: Tomcat startup error!
From: red phoenix [mailto:rodphoe...@gmail.com] Subject: Tomcat startup error! Warn: Failed to scan JAR [jndi:/localhost/examples/WEB-INF/lib/standard.jar] from WEB-INF/lib java.io.FileNotFoundException: c:\apache-tomcat-7.0.12\temp\jar_cache1803949900871975219.tmp (Another program is using this file, process can't visit) But when I shutdown tomcat again,and startup tomcat,it raise above warning information again! Why? How to get rid of above warning? Since you're on Windows, you may want to set the antiJARLocking attribute in the Context element of your webapp. Read about it here: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html - 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: High Availability in Tomcat?
Take a look at the Parallel Deployment feature in Tomcat 7 http://tomcat.apache.org/tomcat-7.0-doc/config/context.html Can someone explain how to do actually do this? I have read the docs at the link above, and think I understand that you have to manually craft a context.xml file for both v1 and v2 of the war files. However the documentation isn't that clear to me - perhaps we could add a step 1, step 2 guide of actually how to do it. Before anyone says well supply a patch, I am happy to - I just want to understand how to use the feature first Thanks Chris
Re: High Availability in Tomcat?
Hi Chris, The easiest way is to deploy files with the name X##Y.war, where X is the usual name you have been using (ROOT, for example) and Y is any string what should be alphabetically located after the previous ones you used. It is as easy as that. You can achieve it doing this, without making changes to the context.xml files, which maybe doesn't even exist in your case. . On Sat, May 14, 2011 at 7:40 AM, chris derham ch...@derham.me.uk wrote: Take a look at the Parallel Deployment feature in Tomcat 7 http://tomcat.apache.org/tomcat-7.0-doc/config/context.html Can someone explain how to do actually do this? I have read the docs at the link above, and think I understand that you have to manually craft a context.xml file for both v1 and v2 of the war files. However the documentation isn't that clear to me - perhaps we could add a step 1, step 2 guide of actually how to do it. Before anyone says well supply a patch, I am happy to - I just want to understand how to use the feature first Thanks Chris
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
Re: Canceling Download on IIS7 with ISAPI Redirector 1.2.31 causes 100% CPU usage
eurotrans-Verlag wrote:
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?
A guess :
IIS and the isapi_redirector are one process, and Tomcat and the servlet are another
process. The isapi_redirector makes a connection to Tomcat, sends the request over it.
The servlet starts running and producing output, quite a lot and quite fast, over that
connection.
The isapi_redirector reads the servlet output, and writes it to the client
connection.
Now the client closes the connection, and isapi_redirector finds a closed socket the next
time it tries to write to the client. It writes this error to the logfile, and stops
trying to send output to the client (well, it cannot anymore, the socket is closed).
But in the meantime the servlet keeps producing output and sending it to
isapi_redirector.
So either isapi_redirector has a way to stop the servlet and discarding any servlet output
still pending, or else it is forced to read and discard whatever the servlet is still
sending, until the servlet decides to stop by itself.
Maybe the 100% CPU usage is happening while isapi_redirector is reading and discarding
whatever remains of the servlet output ? Since there is no client connection anymore to
slow things down, this is bound to be rather fast and cpu-intensive.
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.
-
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
ServerFactory in Tomcat 7
ServerFactory is gone from Tomcat 7. What is now the preferred way of getting hold of the server and, later down the road, of running services? You should really expand the migration document. To say that there have been many changes and we should review the JavaDoc for the relevant API is radically inadequate! Thanks, -- O.L. - 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
eurotrans-Verlag wrote: 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, Remember, there are 2 separate connections : the connection of the client to IIS+isapi_redirector, and the connection from IIS+isapi_redirector to Tomcat+servlet. The servlet will only throw an I/O exception if that second connection is closed. So it all depends on whether the isapi_redirector closes the connection to Tomcat also, when the client has closed its connection to IIS. 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? I have no idea. We need Mladen or Rainer here.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Suggestions for really getting to the bottom of memory leak issues on hot-deploys
[from your blog entry] I also think that logging leaks may be more helpful than using part of manager, because many don't deploy manager (they remove it). it is logged when the application is stopped, on recent tomcat 6 and 7. I think your approach to finding leaks by performing comparisons is not the most efficient. What I usually do to find the leak is to use MAT (eclipse memory analyzer, as you used too) and its class loader explorer. There I find the instance of org.apache.catalina.loader.WebappClassLoader that corresponds to my webapp and right-click to ask path to GC roots/exclude all phantom/weak/soft, etc. references. There I usually see the cause of the leak vey quickly. I you find no strong reference to your classloaders then you might have encountered some JDK bug... You should use a recent one to avoid some (at least 6.0u21). Sylvain On 10 mai 2011, at 21:55, Gary Weaver wrote: Here's what I did and what little I came up with: http://stufftohelpyouout.blogspot.com/2011/05/diagnosing-webappportlet-hot-deploy.html I'm definitely not an expert at diagnosing leaks, so if you have any recommendations/comments, please let me know. I unfortunately started off just thinking I could tune JVM settings, not just by bumping up permgen but by adding things like: -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled But, I was (really) wrong as you can see in the post, along with the various tools used to try to identify what was causing the issue(s). It doesn't seem like determining exactly what is leaking memory (at least in the case of permgen and hot-redeploys/hot-deploys) is a whole lot easier than it was years ago, unless I'm doing something wrong, which I most likely am. Thanks in advance for any feedback! Gary - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
