Re: Basic Question
For starting Tomcat in Eclipse, check this out: http://www.eclipsetotale.com/tomcatPlugin.html As for the other part, I'm not really sure at all. Good luck, though. Zach On Apr 16, 2010, at 3:07 AM, Rhino wrote: I hope someone will take pity on me and help me with this very basic question. I was moderately fluent with servlets and Tomcat several years ago but haven't touched them in a while. I'm trying to get back into servlets now. I am having trouble getting my servlets to start in Tomcat. I inevitably get a 404 error. I am running Tomcat 6.0.26 on Windows XP SP2. The sample applications in Tomcat run fine. My servlets are in Eclipse 3.5.2. They compile fine and I have used the Tomcat menu to export them to the war file directory; no error gets reported when I do the export. I did a manual deploy of the war file from the war file to deplay section of the Tomcat Manager page. When I start the Tomcat Manager in my browser, it shows several servlets, including the examples and the servlets that I have deployed myself. In each case, my own servlets seem to be started just fine. All of them say running, the number of sessions is 0 for each of them, and all of them have stop, reload and undeploy options which are clickable and a start option which is not clickable. To me, that says these puppies are started and there is no error in any of them. However, when I click on my servlets, like /FileUploadServlet for example, I get this: HTTP Status 404 - /FileUploadServlet/ *type* Status report *message* _/FileUploadServlet/_ *description* _The requested resource (/FileUploadServlet/) is not available._ Apache Tomcat/6.0.26 I feel sure that I've simply neglected to do something simple and straightforward but my memory is failing me. I can't remember what other steps are needed to get a servlet configured so that it runs in Tomcat. I was going to try to run the servlet in Eclipse but I'm darned if I can remember how to start it there either. Can someone help me out? -- Rhino - 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: Proposal : port mod_expires in java as ExpiresFilter Servlet Filter
Hello Christopher,
I imagine the project crew has been very busy these days. Do you
have feedbacks on the adaptations and explanations I did ? Is there
anything I could iterate on ?
To rephrase my previous email :
* I reduced the number of comparison against 'nulls' as you suggested.
I did this introducing a method
'isEligibleToExpirationHeaderGeneration(request)' with several
intermediate 'return' statements ; I found it easier to code than to
use nested if/else statements.
* The reason why I introduced the complexity of trapping the
'onStartWriteResponseBody' event is that I tried my best to implement
in ExpiresFilter the same behavior as in Apache Httpd mod_expires.
Cyrille
On Mon, Mar 29, 2010 at 8:32 PM, Cyrille Le Clerc clecl...@apache.org wrote:
Thanks for your fast feedbacks Christopher,
I updated the patch proposed on Bugzilla 48998 to include your advice
to limit the number of null checks. The implementation I found is
slightly different than your proposal but the idea remain the same.
Please note that I only modified the patch and not yet
ExpiresFilter.java on the google-code project as my priority is the
Tomcat proposal.
Regarding the simplification of generating expiration headers just
after 'response.setContentType()' is called rather than after the
first write in the response body, I didn't follow this way because
applications could add/set 'Cache-Control' and/or 'Expires' header
after invoking 'response.setContentType()'.
My understanding is that the filter must work after
'setContentType()', 'set/addHeader(Cache-Control, ...)' and
'set/addHeader(Expires, ...)' have been called but we don't know
which ones will be called and in which order they will be called.
This is the reason why I unfortunately added the complexity to trap
the 'onStartWriteResponseBody' event.
Cyrille
On Mon, Mar 29, 2010 at 3:20 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Cyrille,
On 3/26/2010 12:43 PM, Cyrille Le Clerc wrote:
I have proposed with bugzilla 48998 a port of Apache mod_expires in
Java as ExpiresFilter Servlet Filter.
Cool.
I detailed a standalone version of this filter on
http://code.google.com/p/xebia-france/wiki/ExpiresFilter . Moreover, I
tried my best to provide very detailed javadocs and docs (in filter.html).
The proposed contribution is slightly different than the standalone
one because it uses Tomcat logging, few Servlet 3 enhancements and
Tomcat engine in the test cases.
I read-through your code on code.google.com and I can see a couple areas
where I think improvements might be made:
- - In getExpirationDate, you check for the local 'configuration' being
null several times in a row. In each case, the configuration may be set
given a different 'level' of configuration. If the configuration gets
set, several checks must still be made to see if it is null. You could
mail out early and avoid some of these checks like this:
if(configuration == null) {
configuration = ...;
if(configuration == null) {
// try another strategy
configuration = ...;
if(configuration == null) {
...
}
}
}
I think can save a bit of CPU time without much in the way of code
complexity.
- - You might be able to wrap the Response class and check for the setting
of the Content-Type header, instead of wrapping the response in order to
intercept the first buffer flush to the client. Do you think that would
work? It certainly would remove a lot of complexity from your code.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuwqQwACgkQ9CaO5/Lv0PDdwgCgrSHwmgUTDWybmk6/G1+AqNzY
kCQAn0zVrQBARihaoQkfBJRtKYkjvsjs
=kBWG
-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: mod_jk question about socket_timeout
Recent versions of mod_jk allow a very fine-grained response timeout configuration, so that you can e.g. set a general response timeout to 20 seconds and a longer timeout like 60 seconds for special URLs you expect to take longer like report generation. The cases where you would need short timeouts are the cping/cpong and during connection setup. For the latter there is now also a special timeout, so that you can actually drop the socket timeout. Have a look at: http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html which tries to describe the possible timepouts and their implications in great length. Thanks for your reply Rainer. I have had a read of that (very helpful) document but I guess what I was wondering was if socket_timeout would close a socket purely due to inactivity. The doc mentions timing out on 'operations', which I would take to mean establishing a connection or waiting for an ACK but actually it does seem to drop the connection purely because it's inactive. Cheers, Phil. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Trouble accessing content in webapps/ROOT
HTTPD is serving them rather than Tomcat. Configure a separate document root for HTTPD and the we can fix your connector config. p On 15 Apr 2010, at 18:31, laredotornado laredotorn...@gmail.com wrote: What specifically is wrong? Why are the pages being served without being compiled? Thanks, - Dave Konstantin Kolinko wrote: 2010/4/15 laredotornado laredotorn...@gmail.com: Hi, I'm using Tomcat 6.0.26 with Apache 2.2 on Mac 10.6.3. I want to use http://localhost/ to access content in my $CATALINA_HOME/webapps/ ROOT/ directory. However, when I visit http://localhost/index.jsp, I just get the raw page with all the uncompiled, JSP code. Below is the directive I'm using in my httpd.conf file. Any thoughts? Yes, your configuration is wrong. Have you read the manuals, I mean the proper ones at http://tomcat.apache.org/ ? There should be a warning somewhere, that you must not point Apache to your Tomcat appbase. (Pointing it to your ROOT application is a lesser crime, but still similar to the original one). DocumentRoot /Library/Tomcat/Home/webapps/ROOT Directory /Library/Tomcat/Home/webapps/ROOT Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all /Directory JkMount (...) I am successfully able to access JSP content in other webapps directories other than ROOT. Thanks, - Dave Best regards, Konstantin Kolinko - 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/Trouble-accessing-content-in-webapps-ROOT-tp28256603p28258290.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: question about APR based native library
On 15 Apr 2010, at 19:15, Bill Au bill.w...@gmail.com wrote: I am using 6.0.26. The native library is loaded. I am not as concern about SSL since most of our application don't use SSL. I am guessing that most people don't use the native library. Why, what makes you think that? One of my concern is stability. With a smaller user community, is the native code less stable than the pure Java code? Less usage could mean that there may be bugs that have not been shaken out yet. You're making an assumption based on assumption. Using APR gives you access to the same code libs used by HTTPD, which has a fairly large community. p Bill On Thu, Apr 15, 2010 at 1:03 PM, Jeffrey Janner jeffrey.jan...@polydyne.com wrote: Other than the different SSL implementation? It depends on the release of Tomcat you are using. 5.5.28 (and some release of 6.x) won't properly recognize the library. That is fixed in current releases. -Original Message- From: Bill Au [mailto:bill.w...@gmail.com] Sent: Thursday, April 15, 2010 9:25 AM To: Tomcat Users List Subject: question about APR based native library Are there any reasons I shouldn't use the APR based native libaray? Or at least things that I should be aware of if I do use it? According to the documentation using the native library will give better scalability and performance. I want to understand if there are any downside since with most things there are both upside and downside. Bill *** 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 8443 to 443 problem
I can change the redirectPort at runtime through managed bean org.apache.catalina.mbeans.ConnectorMBean to 443. When I do that it works immediately but after server restart the port is back to 8443. On Thu, Apr 15, 2010 at 6:24 PM, Me Self wmso...@gmail.com wrote: I am trying to use port 443 for https - without success so far. I changed from 8443 to 443 in two places in server.xml: Connector protocol=HTTP/1.1 port=80 ... redirectPort=443 / ... Connector protocol=HTTP/1.1 SSLEnabled=true port=443 ... scheme=https secure=true clientAuth=false keystoreFile=... keystorePass=... sslProtocol = TLS / But apparently this is not enough because when I navigate to a confidential part of the web app tomcat sends a http 302 redirect to port 8443 still instead of 443.. What am i missing? -- Mvh Søren Poulsen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 8443 to 443 problem
2010/4/16 Me Self wmso...@gmail.com: I can change the redirectPort at runtime through managed bean org.apache.catalina.mbeans.ConnectorMBean to 443. When I do that it works immediately but after server restart the port is back to 8443. I see two options: a) either there is a misprint somewhere - unknown attributes are ignored when parsing server.xml, especially in 5.5. The 6.0 would print a message if it can detect that there is no property with the given name in the class that this XML element configures. b) the file that you are changing is not the one that is actually used. I do not use JBoss, so there might be differences with what I know. E.g., you are saying about context.xml, but in Tomcat that is configured in server.xml. By the way, AFAIK, SSLEnabled=true is not needed/not available in Tomcat 5.5, (no harm here, because unknown attribute will just be ignored, as I wrote above). Thus it looks like a Tomcat 6.0 configuration. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: question about APR based native library
On 4/16/2010 6:17 AM, Pid * wrote: On 15 Apr 2010, at 19:15, Bill Aubill.w...@gmail.com wrote: I am using 6.0.26. The native library is loaded. I am not as concern about SSL since most of our application don't use SSL. I am guessing that most people don't use the native library. Why, what makes you think that? One of my concern is stability. With a smaller user community, is the native code less stable than the pure Java code? Less usage could mean that there may be bugs that have not been shaken out yet. You're making an assumption based on assumption. Using APR gives you access to the same code libs used by HTTPD, which has a fairly large community. ^^ That's probably the understatement of the year so far. D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk question about socket_timeout
On 16.04.2010 11:20, Philip Wigg wrote: Recent versions of mod_jk allow a very fine-grained response timeout configuration, so that you can e.g. set a general response timeout to 20 seconds and a longer timeout like 60 seconds for special URLs you expect to take longer like report generation. The cases where you would need short timeouts are the cping/cpong and during connection setup. For the latter there is now also a special timeout, so that you can actually drop the socket timeout. Have a look at: http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html which tries to describe the possible timepouts and their implications in great length. Thanks for your reply Rainer. I have had a read of that (very helpful) document but I guess what I was wondering was if socket_timeout would close a socket purely due to inactivity. The doc mentions timing out on 'operations', which I would take to mean establishing a connection or waiting for an ACK but actually it does seem to drop the connection purely because it's inactive. The exact behaviour of the socket_timeout is dependent on the platform and mod_jk version. It is not supposed to time out during wait for response, but I won't say it's 100% safe to rely on that. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic Question
Can you remind me how to do that (or where to find documentation describing it)? FileUploadServlet is one that I wrote some time back and it has a web.xml file associated with it. I'm pretty sure I created it myself although I don't actually remember doing so at this point. Here are the current contents but I'm not sure if this is still how the web.xml should look at this point: ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; web-app servlet servlet-nameform/servlet-name servlet-classupload.UploadForm/servlet-class /servlet servlet servlet-nameservlet/servlet-name servlet-classupload.UploadServlet/servlet-class init-param param-nameuploadDir/param-name param-valueuploads/param-value /init-param /servlet servlet-mapping servlet-nameform/servlet-name url-pattern/form/url-pattern /servlet-mapping servlet-mapping servlet-nameservlet/servlet-name url-pattern/servlet/url-pattern /servlet-mapping /web-app Also, does this file need to be put into Tomcat somehow so that Tomcat can see it? If so, what is the proper mechanism to do so? Or does the act of exporting to the war file do that automagically? Again, my memory is really fuzzy on this stuff and I don't remember where these techniques are described. -- Rhino Joseph M Morgan wrote: Did you configure your servlets in your web.xml properly? Also...it sounds as though you are deploying each servlet in its own app. Make sure you are invoking the servlet through the proper app. -Original message- From: Rhino rhi...@sympatico.ca To: tomcat-user tomcat-u...@jakarta.apache.org Sent: Fri, Apr 16, 2010 01:07:29 GMT+00:00 Subject: Basic Question I hope someone will take pity on me and help me with this very basic question. I was moderately fluent with servlets and Tomcat several years ago but haven't touched them in a while. I'm trying to get back into servlets now. I am having trouble getting my servlets to start in Tomcat. I inevitably get a 404 error. I am running Tomcat 6.0.26 on Windows XP SP2. The sample applications in Tomcat run fine. My servlets are in Eclipse 3.5.2. They compile fine and I have used the Tomcat menu to export them to the war file directory; no error gets reported when I do the export. I did a manual deploy of the war file from the war file to deplay section of the Tomcat Manager page. When I start the Tomcat Manager in my browser, it shows several servlets, including the examples and the servlets that I have deployed myself. In each case, my own servlets seem to be started just fine. All of them say running, the number of sessions is 0 for each of them, and all of them have stop, reload and undeploy options which are clickable and a start option which is not clickable. To me, that says these puppies are started and there is no error in any of them. However, when I click on my servlets, like /FileUploadServlet for example, I get this: HTTP Status 404 - /FileUploadServlet/ *type* Status report *message* _/FileUploadServlet/_ *description* _The requested resource (/FileUploadServlet/) is not available._ Apache Tomcat/6.0.26 I feel sure that I've simply neglected to do something simple and straightforward but my memory is failing me. I can't remember what other steps are needed to get a servlet configured so that it runs in Tomcat. I was going to try to run the servlet in Eclipse but I'm darned if I can remember how to start it there either. Can someone help me out? -- Rhino - 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: Basic Question
Depends upon how geeky you want it. You can try this, as it will be certainly the most definitive answer, but somewhat like beef jerky to digest: http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd You could start here for a everything you want to know: http://jcp.org/aboutJava/communityprocess/mrel/jsr154/index2.html But I sometimes like to reference something more quick and dirty, but nicely done: http://wiki.metawerx.net/wiki/Web.xml -Original Message- From: Rhino [mailto:rhi...@sympatico.ca] Sent: Friday, April 16, 2010 7:25 AM To: Tomcat Users List Subject: Re: Basic Question Can you remind me how to do that (or where to find documentation describing it)? FileUploadServlet is one that I wrote some time back and it has a web.xml file associated with it. I'm pretty sure I created it myself although I don't actually remember doing so at this point. Here are the current contents but I'm not sure if this is still how the web.xml should look at this point: ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN http://java.sun.com/j2ee/dtds/web-app_2_2.dtd; web-app servlet servlet-nameform/servlet-name servlet-classupload.UploadForm/servlet-class /servlet servlet servlet-nameservlet/servlet-name servlet-classupload.UploadServlet/servlet-class init-param param-nameuploadDir/param-name param-valueuploads/param-value /init-param /servlet servlet-mapping servlet-nameform/servlet-name url-pattern/form/url-pattern /servlet-mapping servlet-mapping servlet-nameservlet/servlet-name url-pattern/servlet/url-pattern /servlet-mapping /web-app Also, does this file need to be put into Tomcat somehow so that Tomcat can see it? If so, what is the proper mechanism to do so? Or does the act of exporting to the war file do that automagically? Again, my memory is really fuzzy on this stuff and I don't remember where these techniques are described. -- Rhino Joseph M Morgan wrote: Did you configure your servlets in your web.xml properly? Also...it sounds as though you are deploying each servlet in its own app. Make sure you are invoking the servlet through the proper app. -Original message- From: Rhino rhi...@sympatico.ca To: tomcat-user tomcat-u...@jakarta.apache.org Sent: Fri, Apr 16, 2010 01:07:29 GMT+00:00 Subject: Basic Question I hope someone will take pity on me and help me with this very basic question. I was moderately fluent with servlets and Tomcat several years ago but haven't touched them in a while. I'm trying to get back into servlets now. I am having trouble getting my servlets to start in Tomcat. I inevitably get a 404 error. I am running Tomcat 6.0.26 on Windows XP SP2. The sample applications in Tomcat run fine. My servlets are in Eclipse 3.5.2. They compile fine and I have used the Tomcat menu to export them to the war file directory; no error gets reported when I do the export. I did a manual deploy of the war file from the war file to deplay section of the Tomcat Manager page. When I start the Tomcat Manager in my browser, it shows several servlets, including the examples and the servlets that I have deployed myself. In each case, my own servlets seem to be started just fine. All of them say running, the number of sessions is 0 for each of them, and all of them have stop, reload and undeploy options which are clickable and a start option which is not clickable. To me, that says these puppies are started and there is no error in any of them. However, when I click on my servlets, like /FileUploadServlet for example, I get this: HTTP Status 404 - /FileUploadServlet/ *type* Status report *message* _/FileUploadServlet/_ *description* _The requested resource (/FileUploadServlet/) is not available._ Apache Tomcat/6.0.26 I feel sure that I've simply neglected to do something simple and straightforward but my memory is failing me. I can't remember what other steps are needed to get a servlet configured so that it runs in Tomcat. I was going to try to run the servlet in Eclipse but I'm darned if I can remember how to start it there either. Can someone help me out? -- Rhino - 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 - To unsubscribe, e-mail:
Re: Basic Question
2010/4/16 Rhino rhi...@sympatico.ca:
However, when I click on my servlets, like /FileUploadServlet for example, I
get this:
HTTP Status 404 - /FileUploadServlet/
The keyword here is welcome page. If your WAR file does not have
index.jsp or index.html, or some explicit mapping for its root
address, you will get a 404 response trying to access the root of your
webapp.
According to the web.xml that you posted, your application will
respond to the following URLs:
/FileUploadServlet/form
/FileUploadServlet/servlet
Some pointers:
http://tomcat.apache.org/tomcat-6.0-doc/index.html
http://tomcat.apache.org/tomcat-6.0-doc/appdev/index.html
http://wiki.eclipse.org/WTP_Tomcat_FAQ
You may also want to know, that ${catalina.base}/conf/web.xml provides
the defaults for your WEB-INF/web.xml.
Do not change that common file (in /conf), though, unless it is really needed.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 8443 to 443 problem
b) the file that you are changing is not the one that is actually used. I do not use JBoss, so there might be differences with what I know. E.g., you are saying about context.xml, but in Tomcat that is configured in server.xml. I found out jboss uses a hybrid of Tomcats server.xml file and its own central way of setting ports for all its services. The file for central port settings in jboss 5.1.0.ga is /server/default/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml, but its faily obscure. Inside the bindings-jboss-beans.xml theres a piece of XSLT that transforms and overwrites the Connector tag from the server.xml file. The XSLT works from a base port and theres no direct mention of 8443 which is why I could find the config with find . -exec grep 8443 Some of the XSLT transformation wont match the connector tags in server.xml if the ports have been changed in server.xml and I found lots of posts from people trying that approach - all in all it looks like an extremely flaky way of controlling ports centrally but maybe its just because im doing it wrong. This is what worked for me: Change this line in bindings-jboss-beans.xml : xsl:attribute name=redirectPortxsl:value-of select=$portHttps //xsl:attribute To: xsl:attribute name=redirectPortxsl:value-of select=443 //xsl:attribute (I believe this breaks the general jboss port settings based on having a single base port from which other ports are calculated) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Hung threads
*** 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. ---BeginMessage--- Well, it's definitely deadlocking once it hits the maxThreads limit. I had this instance and another one on the same machine both hit the max last night and the acceptor stopped waiting on workers. All the workers show their normal wait state, and some of the Pollers showed they were waiting on workers also. What I appear to be seeing is that the requests come in and get processed on a minimal number of workers, but at some point, new workers are getting created until we reach the maxThreads limit (150). I'm not seeing a traffic load that indicates that it should ever be using that many workers, there are only about 15-20 end users in the app at any one time. I'm not seeing this on other systems running the same version of the app tomcat, although they are running a much older native library. I've been monitoring the instance using jconsole. On the instance that died early last night, they were sitting at about 135 worker threads at 8:00am and stayed there all day, even with some cursory logging in and checking a few pages during the day. Then, at about 7:00pm, when the Asia user based started working, the Threads graph in jconsole starts climbing, levels for about 30 minutes, and then climbed the rest of the way until it hit the 150 limit. Almost as though it wasn't using the bulk of the existing worker threads. The resulting threads looked just like those in the previous thread dump -- all workers in normal wait state, but the Acceptor waiting on workers. Question: Could there be something that our programmers are doing (or more likely NOT doing) that would allow workers to return to waiting, but not actually be free for work? Otherwise, I'd have to assume something in the native library is mucking up the thread pool count. Jeff -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, April 15, 2010 11:42 AM To: Tomcat Users List Subject: Re: Hung threads -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 4/15/2010 10:19 AM, Konstantin Kolinko wrote: +1. If it is stuck there, it will not accept any more incoming requests. Thanks for the confirmation that Jeffrey is deadlocked. It might be that you bumped into BZ 48843 https://issues.apache.org/bugzilla/show_bug.cgi?id=48843 Heh. This guy is bouncing from one bug to the next, here. Sorry, Jeffrey. :( A patch for it is already available, proposed, and has enough votes, so it will be applied shortly. That will be 5.5.30, though. Jeffrey, do you have the inclination to apply this patch to your TC instance? Compiling TC 5.5 was relatively simply IIRC. Or, maybe someone would be willing to roll you a binary patch. - -chris ---End Message--- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: question about APR based native library
Sorry about my assumption(s). I made them based on information I gathered from talking to Tomcat users I know. My sample size is small so my assumptions may not be valid. By smaller user community I don't mean APR. I mean the APR connector Http11AprProtocol. Bill On Fri, Apr 16, 2010 at 6:17 AM, Pid * p...@pidster.com wrote: On 15 Apr 2010, at 19:15, Bill Au bill.w...@gmail.com wrote: I am using 6.0.26. The native library is loaded. I am not as concern about SSL since most of our application don't use SSL. I am guessing that most people don't use the native library. Why, what makes you think that? One of my concern is stability. With a smaller user community, is the native code less stable than the pure Java code? Less usage could mean that there may be bugs that have not been shaken out yet. You're making an assumption based on assumption. Using APR gives you access to the same code libs used by HTTPD, which has a fairly large community. p Bill On Thu, Apr 15, 2010 at 1:03 PM, Jeffrey Janner jeffrey.jan...@polydyne.com wrote: Other than the different SSL implementation? It depends on the release of Tomcat you are using. 5.5.28 (and some release of 6.x) won't properly recognize the library. That is fixed in current releases. -Original Message- From: Bill Au [mailto:bill.w...@gmail.com] Sent: Thursday, April 15, 2010 9:25 AM To: Tomcat Users List Subject: question about APR based native library Are there any reasons I shouldn't use the APR based native libaray? Or at least things that I should be aware of if I do use it? According to the documentation using the native library will give better scalability and performance. I want to understand if there are any downside since with most things there are both upside and downside. Bill *** 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat Shutdown suddenly / random
Hi folks, we are facing a serious problem with our tomcat which shuts itself down after some time of running. this problem first arises after we switched to our new server. we are using tomcat 6.0.26 (also tried different other 5.5.x, 6.0.x versions). the old server was a 32 bit red hat enterprise linux system. the new server is a 64 bit debian 5 (also tried debian 6). the log always gives us the following message, so as if the tomcat has been cleanly shutdown, which is really strange. 16.04.2010 11:52:42 org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 16.04.2010 11:52:43 org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina 16.04.2010 11:52:43 org.apache.coyote.http11.Http11Protocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8080 we also tried to switch the shutdown-message and the shutdown-port, without effect. the tomcat process is started with a non-root-user. the server runs for 15 minutes to 8 hours before it happens. any suggestions or help would be nice. cya, peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Shutdown suddenly / random
On 16/04/2010 17:21, Peter Borkowski wrote: Hi folks, we are facing a serious problem with our tomcat which shuts itself down after some time of running. this problem first arises after we switched to our new server. we are using tomcat 6.0.26 (also tried different other 5.5.x, 6.0.x versions). the old server was a 32 bit red hat enterprise linux system. the new server is a 64 bit debian 5 (also tried debian 6). the log always gives us the following message, so as if the tomcat has been cleanly shutdown, which is really strange. 16.04.2010 11:52:42 org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 16.04.2010 11:52:43 org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina 16.04.2010 11:52:43 org.apache.coyote.http11.Http11Protocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8080 That looks like a fairly orderly shutdown to me. What is immediately before it in this log and in the access logs at the time? we also tried to switch the shutdown-message and the shutdown-port, without effect. If something is calling an init.d/tomcat script then it won't matter. Tomcat only listens on the localhost address for that message anyway. the tomcat process is started with a non-root-user. the server runs for 15 minutes to 8 hours before it happens. To confirm: are you starting stopping using a JSVC wrapper script? Are there any cron jobs (or similar) which might interfere with the server? Were there any users logged into the system at the time of shutdown? Is there anything in the .bash_history (or whatever shell you're using) of said user(s)? p any suggestions or help would be nice. cya, peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org signature.asc Description: OpenPGP digital signature
Exception report - HTTP Status 500 -
Hi, I have installed on my Debian GNU/Linux Lenny system tomcat5.5. When the system boot, and in firefox browser opens the tomcat 's page: http://localhost:8180/ , I get an error message: --- type Exception report message description The server encountered an internal error () that \ prevented it from fulfilling this request. exception java.security.AccessControlException: access denied \ (java.lang.RuntimePermission accessClassInPackage.org.apache.coyote) java.security.AccessControlContext.checkPermission\ (AccessControlContext.java:342) java.security.AccessController.checkPermission\ (AccessController.java:553) java.lang.SecurityManager.checkPermission(SecurityManager.java:549) java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1529) sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:291) java.lang.ClassLoader.loadClass(ClassLoader.java:316) java.lang.ClassLoader.loadClass(ClassLoader.java:316) java.lang.ClassLoader.loadClass(ClassLoader.java:268) java.lang.ClassLoader.loadClassInternal(ClassLoader.java:336) org.apache.coyote.http11.InternalOutputBuffer.sendStatus\ (InternalOutputBuffer.java:452) org.apache.coyote.http11.Http11Processor.prepareResponse\ (Http11Processor.java:1617) org.apache.coyote.http11.Http11Processor.action\ (Http11Processor.java:967) org.apache.coyote.Response.action(Response.java:181) org.apache.coyote.http11.InternalOutputBuffer.doWrite\ (InternalOutputBuffer.java:576) org.apache.coyote.Response.doWrite(Response.java:560) org.apache.catalina.connector.OutputBuffer.realWriteBytes\ (OutputBuffer.java:361) org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:323) org.apache.tomcat.util.buf.IntermediateOutputStream.write\ (C2BConverter.java:236) sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:220) sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:290) sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:294) sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:140) java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) org.apache.tomcat.util.buf.WriteConvertor.flush(C2BConverter.java:185) org.apache.tomcat.util.buf.C2BConverter.flushBuffer\ (C2BConverter.java:128) org.apache.catalina.connector.OutputBuffer.realWriteChars\ (OutputBuffer.java:536) org.apache.tomcat.util.buf.CharChunk.append(CharChunk.java:255) org.apache.catalina.connector.OutputBuffer.write\ (OutputBuffer.java:456) org.apache.catalina.connector.CoyoteWriter.write\ (CoyoteWriter.java:143) org.apache.jasper.runtime.JspWriterImpl.flushBuffer\ (JspWriterImpl.java:119) org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:326) org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:342) org.apache.jsp.index_jsp._jspService(index_jsp.java:50) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke\ (NativeMethodAccessorImpl.java:57) sun.reflect.DelegatingMethodAccessorImpl.invoke\ (DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:616) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) java.security.AccessController.doPrivileged(Native Method) javax.security.auth.Subject.doAsPrivileged(Subject.java:537) org.apache.catalina.security.SecurityUtil.execute\ (SecurityUtil.java:276) org.apache.catalina.security.SecurityUtil.doAsPrivilege\ (SecurityUtil.java:162) When I refresh the webpage, I get the Tomcat5.5 homepage, without any errors. -- Regards, Paul Chany You can freely correct me in my English. http://csanyi-pal.info - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Shutdown suddenly / random
Peter, could it be that something is sending your tomcat process a TERM signal, logfiles in /var/log might tell something ? or one of your applications issues a System.exit() under certain circumstances ? regards, Harry 2010/4/16 Peter Borkowski apocalyps...@gmx.de Hi folks, we are facing a serious problem with our tomcat which shuts itself down after some time of running. this problem first arises after we switched to our new server. we are using tomcat 6.0.26 (also tried different other 5.5.x, 6.0.x versions). the old server was a 32 bit red hat enterprise linux system. the new server is a 64 bit debian 5 (also tried debian 6). the log always gives us the following message, so as if the tomcat has been cleanly shutdown, which is really strange. 16.04.2010 11:52:42 org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 16.04.2010 11:52:43 org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina 16.04.2010 11:52:43 org.apache.coyote.http11.Http11Protocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8080 we also tried to switch the shutdown-message and the shutdown-port, without effect. the tomcat process is started with a non-root-user. the server runs for 15 minutes to 8 hours before it happens. any suggestions or help would be nice. cya, peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic Question
Konstantin Kolinko wrote:
2010/4/16 Rhino rhi...@sympatico.ca:
However, when I click on my servlets, like /FileUploadServlet for example, I
get this:
HTTP Status 404 - /FileUploadServlet/
The keyword here is welcome page. If your WAR file does not have
index.jsp or index.html, or some explicit mapping for its root
address, you will get a 404 response trying to access the root of your
webapp.
According to the web.xml that you posted, your application will
respond to the following URLs:
/FileUploadServlet/form
/FileUploadServlet/servlet
As Homer Simpson would say: D'oh!. I was clicking on the application
from the Tomcat Manager so it was trying to launch FileUploadServlet,
i.e. it was trying to go to http://localhost:8080/FileUploadServlet. As
soon as I added /form to the URL it came up fine! It has been at least
four or five years since I last played with a servlet so I simply forgot
about adding that part of the URL. Thank you!!!
Some pointers:
http://tomcat.apache.org/tomcat-6.0-doc/index.html
http://tomcat.apache.org/tomcat-6.0-doc/appdev/index.html
http://wiki.eclipse.org/WTP_Tomcat_FAQ
You may also want to know, that ${catalina.base}/conf/web.xml provides
the defaults for your WEB-INF/web.xml.
Do not change that common file (in /conf), though, unless it is really needed.
And thanks also for this information! I'll keep it handy.
Best regards,
Rhino
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Exception report - HTTP Status 500 -
On 16/04/2010 19:30, Paul Chany wrote: Hi, I have installed on my Debian GNU/Linux Lenny system tomcat5.5. When the system boot, and in firefox browser opens the tomcat 's page: http://localhost:8180/ , I get an error message: --- type Exception report message description The server encountered an internal error () that \ prevented it from fulfilling this request. exception java.security.AccessControlException: access denied \ (java.lang.RuntimePermission accessClassInPackage.org.apache.coyote) java.security.AccessControlContext.checkPermission\ (AccessControlContext.java:342) java.security.AccessController.checkPermission\ (AccessController.java:553) java.lang.SecurityManager.checkPermission(SecurityManager.java:549) java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1529) sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:291) java.lang.ClassLoader.loadClass(ClassLoader.java:316) java.lang.ClassLoader.loadClass(ClassLoader.java:316) java.lang.ClassLoader.loadClass(ClassLoader.java:268) java.lang.ClassLoader.loadClassInternal(ClassLoader.java:336) org.apache.coyote.http11.InternalOutputBuffer.sendStatus\ (InternalOutputBuffer.java:452) org.apache.coyote.http11.Http11Processor.prepareResponse\ (Http11Processor.java:1617) org.apache.coyote.http11.Http11Processor.action\ (Http11Processor.java:967) org.apache.coyote.Response.action(Response.java:181) org.apache.coyote.http11.InternalOutputBuffer.doWrite\ (InternalOutputBuffer.java:576) org.apache.coyote.Response.doWrite(Response.java:560) org.apache.catalina.connector.OutputBuffer.realWriteBytes\ (OutputBuffer.java:361) org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:323) org.apache.tomcat.util.buf.IntermediateOutputStream.write\ (C2BConverter.java:236) sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:220) sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:290) sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:294) sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:140) java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) org.apache.tomcat.util.buf.WriteConvertor.flush(C2BConverter.java:185) org.apache.tomcat.util.buf.C2BConverter.flushBuffer\ (C2BConverter.java:128) org.apache.catalina.connector.OutputBuffer.realWriteChars\ (OutputBuffer.java:536) org.apache.tomcat.util.buf.CharChunk.append(CharChunk.java:255) org.apache.catalina.connector.OutputBuffer.write\ (OutputBuffer.java:456) org.apache.catalina.connector.CoyoteWriter.write\ (CoyoteWriter.java:143) org.apache.jasper.runtime.JspWriterImpl.flushBuffer\ (JspWriterImpl.java:119) org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:326) org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:342) org.apache.jsp.index_jsp._jspService(index_jsp.java:50) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke\ (NativeMethodAccessorImpl.java:57) sun.reflect.DelegatingMethodAccessorImpl.invoke\ (DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:616) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) java.security.AccessController.doPrivileged(Native Method) javax.security.auth.Subject.doAsPrivileged(Subject.java:537) org.apache.catalina.security.SecurityUtil.execute\ (SecurityUtil.java:276) org.apache.catalina.security.SecurityUtil.doAsPrivilege\ (SecurityUtil.java:162) When I refresh the webpage, I get the Tomcat5.5 homepage, without any errors. Exactly which version of Tomcat 5.5.nn? p -- Regards, Paul Chany You can freely correct me in my English. http://csanyi-pal.info - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org signature.asc Description: OpenPGP digital signature
Re: Hung threads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeffrey, BTW your mailer and/or mail exchanger sucks... it puts your message into the html-only portion of a multipart/alternative message which means that basically your messages don't show up properly. Instead, I see the confidential warning that gets attached to all your messages, sometimes (if I'm lucky) followed by your actual message. Usually, I have to open the attachment that contains your actual text. :( On 4/15/2010 12:57 PM, Jeffrey Janner wrote: I've not got the tools nor training to do a Windows build. The build is not Windows-specific: it's just compiling the Java classes, along with a source patch that you could probably hand-enter given the diff if you don't have a win32 'patch' binary handy. I could gather the tools, but I'd rather not learn by patching a production system. Sounds like a good idea: can you set up a test system that you can pound while you figure out the magic recipe of versions that will yield a stable system? I think it's probably a sudden usage spike by the customer's 3rd-party users. I can increase their max thread count and probably give them relief. Plus then I can really see if there is a possible connection leak going on in my developer's code. It's unlikely that your code is leaking HTTP connections somehow. Maybe JDBC connections, but that's another story. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvIzYUACgkQ9CaO5/Lv0PDY4gCfZQunGew3JAWbESHOZvzPsmJi QCEAn0oUmQLv8ulOATqg68vFPB/0NU2j =/77Z -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Shutdown suddenly / random
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harry, On 4/16/2010 2:35 PM, Harry Metske wrote: could it be that something is sending your tomcat process a TERM signal, logfiles in /var/log might tell something ? or one of your applications issues a System.exit() under certain circumstances ? +1 I'm not sure what the best way is to catch TERM signals. I guess you could write some JNI code to install a signal handler that logs the signal and details (if available) about the process that sent the signal. I don't believe Tomcat has any System.exit calls in it, so you could grep your code looking for such calls. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvIz4IACgkQ9CaO5/Lv0PAT4QCgtsZhK/DtHhS8KVjYUhCA2mdG dVwAn1DOyYGJLIfV5hBl1GWaTF8CZUO3 =ASpm -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: question about APR based native library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 4/15/2010 7:17 PM, Konstantin Kolinko wrote: The main competitors are APR connector vs. Nio connector, as both provide multiplexing aka polling, allowing to serve more sockets than the count of your worker threads. The APR connector sure has a bit more longer history, dating back to TC 5.5. The Nio connector is more modern, available since TC 6.x only, but that is several years already. My (as yet unpublished) performance tests show that APR and NIO offer virtually the same performance. Make sure you set sendFile=true if you are doing any significant static-file serving through your Tomcat instance. less stable than the pure Java code Note, that that also depends on the JRE implementation that you would be using. +1 The APR code is more likely to actually crash your JVM than the pure-Java implementation, but I haven't seen any recent complaints about APR crashing at all. Jeffrey is having a bear of a time getting APR working in his environment due to a number of issues that are all piling up. My advice: set up a testing environment where you can play and perform load testing. Compare the performance of the NIO versus APR connectors. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvI0V0ACgkQ9CaO5/Lv0PB1awCbBSPmpnyo1zPSn0pEmXwBBTVm 1kkAoJtNgbJHSRBCEbQpjhiFhg6ucAS1 =U+zf -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Hung threads
2010/4/16 Jeffrey Janner jeffrey.jan...@polydyne.com Well, it's definitely deadlocking once it hits the maxThreads limit. The worker is returned to the workers pool by an AprEndpoint.recycleWorkerThread(..) call. If that call is skipped, the workers will leak. That is theoretically. I do not remember any reports on such an issue. Do you have any error messages in your logs, or in the catalina.out file (aka the file that catches your stderr stream)? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Exception report - HTTP Status 500 -
If you installed your Tomcat using the Debian package manager, take a look at the tomcat startup script. While it's been a number of years since I used Debian, I seem to remember this from back in the day - look for a statement referencing security or use security or something to that effect and comment it out. Restart Tomcat and see if that doesn't fix it. On Fri, Apr 16, 2010 at 4:41 PM, Pid p...@pidster.com wrote: On 16/04/2010 19:30, Paul Chany wrote: Hi, I have installed on my Debian GNU/Linux Lenny system tomcat5.5. When the system boot, and in firefox browser opens the tomcat 's page: http://localhost:8180/ , I get an error message: --- type Exception report message description The server encountered an internal error () that \ prevented it from fulfilling this request. exception java.security.AccessControlException: access denied \ (java.lang.RuntimePermission accessClassInPackage.org.apache.coyote) java.security.AccessControlContext.checkPermission\ (AccessControlContext.java:342) java.security.AccessController.checkPermission\ (AccessController.java:553) java.lang.SecurityManager.checkPermission(SecurityManager.java:549) java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1529) sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:291) java.lang.ClassLoader.loadClass(ClassLoader.java:316) java.lang.ClassLoader.loadClass(ClassLoader.java:316) java.lang.ClassLoader.loadClass(ClassLoader.java:268) java.lang.ClassLoader.loadClassInternal(ClassLoader.java:336) org.apache.coyote.http11.InternalOutputBuffer.sendStatus\ (InternalOutputBuffer.java:452) org.apache.coyote.http11.Http11Processor.prepareResponse\ (Http11Processor.java:1617) org.apache.coyote.http11.Http11Processor.action\ (Http11Processor.java:967) org.apache.coyote.Response.action(Response.java:181) org.apache.coyote.http11.InternalOutputBuffer.doWrite\ (InternalOutputBuffer.java:576) org.apache.coyote.Response.doWrite(Response.java:560) org.apache.catalina.connector.OutputBuffer.realWriteBytes\ (OutputBuffer.java:361) org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:323) org.apache.tomcat.util.buf.IntermediateOutputStream.write\ (C2BConverter.java:236) sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:220) sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:290) sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:294) sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:140) java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) org.apache.tomcat.util.buf.WriteConvertor.flush(C2BConverter.java:185) org.apache.tomcat.util.buf.C2BConverter.flushBuffer\ (C2BConverter.java:128) org.apache.catalina.connector.OutputBuffer.realWriteChars\ (OutputBuffer.java:536) org.apache.tomcat.util.buf.CharChunk.append(CharChunk.java:255) org.apache.catalina.connector.OutputBuffer.write\ (OutputBuffer.java:456) org.apache.catalina.connector.CoyoteWriter.write\ (CoyoteWriter.java:143) org.apache.jasper.runtime.JspWriterImpl.flushBuffer\ (JspWriterImpl.java:119) org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:326) org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:342) org.apache.jsp.index_jsp._jspService(index_jsp.java:50) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke\ (NativeMethodAccessorImpl.java:57) sun.reflect.DelegatingMethodAccessorImpl.invoke\ (DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:616) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) java.security.AccessController.doPrivileged(Native Method) javax.security.auth.Subject.doAsPrivileged(Subject.java:537) org.apache.catalina.security.SecurityUtil.execute\ (SecurityUtil.java:276) org.apache.catalina.security.SecurityUtil.doAsPrivilege\ (SecurityUtil.java:162) When I refresh the webpage, I get the Tomcat5.5 homepage, without any errors. Exactly which version of Tomcat 5.5.nn? p -- Regards, Paul Chany You can freely correct me in my English. http://csanyi-pal.info - 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 Shutdown suddenly / random
I thought thta a System.exit call would kill the JVM and would therefore not show the clean shutdown in the logs that the OP is seeing... am I wrong about System.exit? Thanks, Carl - Original Message - From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Friday, April 16, 2010 3:58 PM Subject: Re: Tomcat Shutdown suddenly / random -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harry, On 4/16/2010 2:35 PM, Harry Metske wrote: could it be that something is sending your tomcat process a TERM signal, logfiles in /var/log might tell something ? or one of your applications issues a System.exit() under certain circumstances ? +1 I'm not sure what the best way is to catch TERM signals. I guess you could write some JNI code to install a signal handler that logs the signal and details (if available) about the process that sent the signal. I don't believe Tomcat has any System.exit calls in it, so you could grep your code looking for such calls. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvIz4IACgkQ9CaO5/Lv0PAT4QCgtsZhK/DtHhS8KVjYUhCA2mdG dVwAn1DOyYGJLIfV5hBl1GWaTF8CZUO3 =ASpm -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: DB connection error -Tomcat 6 config
Mark, got the profiler downloaded and going. Looking at the link below I see reference to one other link, https://issues.apache.org/bugzilla/show_bug.cgi?id=48837, which seems to reveal the core of my problem. Konstantin has some instructions on there I'll try implementing and see if it helps address the matter. Thanks, Barry -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Friday, March 26, 2010 2:25 PM To: Tomcat Users List Subject: Re: DB connection error -Tomcat 6 config On 26/03/2010 19:22, Propes, Barry L wrote: Mark -- looked for that and got this message: Your search query TimerThread didn't return any results. Please change some terms and refer to HelpOnSearching for more information. Sorry - should have been clearer - just look for that text on the page. I'll see about downloading and implementing the profiler. -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Tuesday, March 23, 2010 5:54 PM To: Tomcat Users List Subject: Re: DB connection error -Tomcat 6 config On 23/03/2010 22:39, Propes, Barry L wrote: I got this again today, and it seems to happen when/if I go into the Tomcat Manager app and either Stop and Start or Reload the app. Should that have a significant bearing on something like a DBCP connection so adversely? I was thinking it was tantamount to shutting down the Tomcat console and restarting itthat not the case? No. It just re-loads the app. Sounds like you have hit a bug in commons-pool / Tomcat's memory leak clean-up code. http://wiki.apache.org/tomcat/MemoryLeakProtection search for TimerThread Mark - 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 - 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 Shutdown suddenly / random
On 16/04/2010 23:43, Carl wrote: I thought thta a System.exit call would kill the JVM and would therefore not show the clean shutdown in the logs that the OP is seeing... am I wrong about System.exit? Yes. It invokes the shutdown hook and that performs a clean shutdown. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DB connection error -Tomcat 6 config
2010/4/17 Propes, Barry L barry.l.pro...@citi.com: Mark, got the profiler downloaded and going. Looking at the link below I see reference to one other link, https://issues.apache.org/bugzilla/show_bug.cgi?id=48837, which seems to reveal the core of my problem. Konstantin has some instructions on there I'll try implementing and see if it helps address the matter. Thanks, Barry Sounds like you have hit a bug in commons-pool / Tomcat's memory leak clean-up code. http://wiki.apache.org/tomcat/MemoryLeakProtection search for TimerThread Probably you meant https://issues.apache.org/bugzilla/show_bug.cgi?id=48971#c5 When the reply goes above the original question (aka top-posting), it is usually hard to read. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: DB connection error -Tomcat 6 config
Yes, that one, as well. Thanks, Konstantin. Sorry about that. -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Friday, April 16, 2010 5:14 PM To: Tomcat Users List Subject: Re: DB connection error -Tomcat 6 config 2010/4/17 Propes, Barry L barry.l.pro...@citi.com: Mark, got the profiler downloaded and going. Looking at the link below I see reference to one other link, https://issues.apache.org/bugzilla/show_bug.cgi?id=48837, which seems to reveal the core of my problem. Konstantin has some instructions on there I'll try implementing and see if it helps address the matter. Thanks, Barry Sounds like you have hit a bug in commons-pool / Tomcat's memory leak clean-up code. http://wiki.apache.org/tomcat/MemoryLeakProtection search for TimerThread Probably you meant https://issues.apache.org/bugzilla/show_bug.cgi?id=48971#c5 When the reply goes above the original question (aka top-posting), it is usually hard to read. 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
