Bundle Tomcat and Test in Eclipse
I am working on a project with specifications to bundle Tomcat7 with a Web Application. I am having trouble with the initial package setup, as this is my first time bundling Tomcat7. I've developed WAR files that have been deployed before. I'm trying to start basic and get the bundle instance of Tomcat7 working in Eclipse. That way, when I compile, it will launch using my version of Tomcat. I've searched online, but have not found exactly what I need to accomplish this. I'm sure my keywords are wrong. I see a lot of items on embedding Tomcat, but this is not what I need. Additional Information Assumptions 1)Users will install the appropriate Java version (due to distribution legal) Needs 1)Deliver custom instance of tomcat with various JDBC and tools included in the libraries. Expectations 1)Users will download a ZIP file or pull it via Git/SVN. No "install" required other than unpacking the files. 2)There will be some minor configuration changes to various Tomcat configs based on the users environment (LDAP, sFTP, databases, etc.) 3)The same file can be downloaded via Linux, Windows or Mac and Tomcat will execute and launch the web application/web services. 4)All development is to be done in Eclipse. Upon testing, Eclipse will launch the bundled version of Tomcat. Can anyone offer any guidance on what I should be looking for? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Java 6u37, 7u09 are available
> -Original Message- > From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] > Sent: Wednesday, October 17, 2012 7:33 AM > To: Tomcat Users List > Subject: Java 6u37, 7u09 are available > > Hi! > > Just noting that Java 6u37, 7u09 were released by Oracle > http://www.oracle.com/technetwork/java/javase/downloads/ > > They contain a number of security fixes. Details are here: > http://www.oracle.com/technetwork/topics/security/javacpuoct2012verbose > -1515981.html > http://www.oracle.com/technetwork/topics/security/javacpuoct2012- > 1515924.html > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > Thanks for the info Konstantin. I might have missed the notice without your passing on the info. I really liked how detailed the Oracle notices were, particularly in light of the bit where they suggest we minimize risks by limiting access via the affected protocols if we are unable to upgrade right away. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting certain ports to certain contexts?
James Lampert wrote: We have a situation: A Tomcat server with a number of contexts. One of those contexts should be available unsecured on port 8080. The others should only be available secured, on port 443. Is there a way we can restrict 8080 to the one unsecured context? I am not specialist, but in http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributes I see this : quote redirectPort If this Connector is supporting non-SSL requests, and a request is received for which a matching requires SSL transport, Catalina will automatically redirect the request to the port number specified here. unquote Let's suppose that the context in question is named "no-https", located in (catalina_base)/webapps/no-https/. And that a request is made for "http://yourserver:8080/no-https";. Seen the above, I would imagine that if that particular context does not have a requiring SSL transport (HTTPS), the request will not be re-directed by the Connector for port 8080, and would thus remain HTTP. On the other hand, if a request is received directly for "https://yourserver:443/no-https";, then it would belong to some servlet filter inserted in that webapp, to send back a redirect response to "http://yourserver:8080/no-https";. But I may imagine wrong, since I am not a specialist. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ask tomcat to look at a specifc folder for the root website
S Ahmed wrote: For my deployment, I have a set directory structure that I use. Is it possible to tell tomcat to look at a specific folder for the ROOT website, instead of in the ../../webapps/ folder? my folder structure is like: /www/myappname/website/ /www/myappname/otherstuff/ I want tomcat to look in my /website/ folder. What about "appBase" in http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Common_Attributes ? The people who write the on-line Tomcat documentation must be getting very frustrated today. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Tomcat bug 53814 - PDF plugin in IE cannot download correctly
Mark Thomas wrote: On 16/10/2012 18:54, David Wall wrote: By the way, the web.xml change we made was suggested in the bug report and seems to resolve it for our IE site visitors. Glad to head that disabling support for range requests works. That seems like a reasonable short-term workaround until someone experiencing this error contacts Adobe. This is not exactly the same issue, but I thought I'd share this. Just to give one an idea of what one is up against (and maybe also the difference between open-source and not-open-source) I found this while searching Google for things related to : Adobe Reader plugin +"Range" +"boundary". http://forums.iis.net/p/1161071/1986957.aspx Summary : - an issue between IIS 7.5 and Adobe Reader plugin, related to byteranges, made it impossible to retrieve PDFs - first reported on Sep 21 2009 - it took MS until Dec 12 2009 (2 months) to come up with an explanation that the problem was in the Adobe plugin - MS hotfix released March 21 2010 (6 months later), in which they apparently acknowledge that the problem was theirs after all (http://support.microsoft.com/kb/979543) - as far as I can tell Adobe never did anything And here is another similar issue on an Adobe forum: http://forums.adobe.com/thread/948331?start=0&tstart=0 - first reported Jan 12 2012 - fix released by Adobe on April 26 2012 (3.5 months later), after strong pressure from some very large organisations (e.g., Citibank) And I'll note that the present thread was opened yesterday, and at least a workaround was provided the same day. And the original bug #53814 took 3 days to be tackled. I wouldn't raise my hopes too high about Adobe ever fixing the underlying bug in the plugin though. It seems it is not only the banks that should be broken up before they get too big to fail. I would suggest that one also includes large dominant software companies. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Thread related MBean questions
On 16/10/2012 17:52, Shanti Suresh wrote: > Greetings. > > I have some questions on finding the number of active threads in Tomcat. > (1) On our QA system, I notice that the currenthreadsBusy MBean is > either zero or one for the 8443 and 8080 connectors. ThreadCount != currentThreadsBusy One is the count of threads, one is the threads that are doing work. > Why then is ThreadCount = 93 when there is not much going on on QA? Because you've previously done enough work for Tomcat to maintain 93 threads. > (2) When I want to graph the thread activity in Tomcat (the thread > Pool usage), which is a better counter to look at - currentThreadsBusy > or "ThreadCount"? Depends what you want know. > It seems like "ThreadCount" is what JConsole displays as "Live Threads". > (3) Why is TotalStartedThreadCount: 264? Is that a cumulative total > since Tomcat was restarted? Yes. p > --Thread-related MBean snippet:- > > Name: Catalina:type=ThreadPool,name="http-apr-8443" > currentThreadsBusy: 1 > ... > > Name: Catalina:type=ThreadPool,name="http-apr-8080" > currentThreadsBusy: 0 > ... > > Name: java.lang:type=Threading > DaemonThreadCount: 85 > PeakThreadCount: 99 > AllThreadIds: Array[long] of length 93 > 135 > 119 > 118 > 117 > ... > > CurrentThreadCpuTime: 46 > CurrentThreadUserTime: 402000 > ThreadCount: 93 > TotalStartedThreadCount: 264 > ThreadCpuTimeSupported: true > ... > ---end of snippet > > Thanks! > > -Shanti > -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Servlet init method called twice (2nd time with null init params)
Hi, Ok so it turned out to be a simple fix. I had not named the servlet (in web.xml) that same as the access url (war). Cheers, Stuart On 17 Oct 2012, at 10:03, Stuart Broad wrote: > Hi, > > Sorry to keep replying to my own question but I gathered two stack traces > from each of the calls to init that may be useful: > > On startup (and this is the servlet also used by the post): > >at > org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1266) >at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1185) >at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1080) >at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5027) >at > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5314) >at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) >at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) >at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) >at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:618) >at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:963) >at > org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1600) >at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) >at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) >at java.util.concurrent.FutureTask.run(FutureTask.java:138) >at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) >at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) >at java.lang.Thread.run(Thread.java:680) > > On calling get (this is the one that fails and has no init-param information): > >at > org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1266) >at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1185) >at > org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:857) >at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136) >at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) >at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) >at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) >at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) >at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927) >at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) >at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) >at > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1001) >at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585) >at > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) >at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) >at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) >at java.lang.Thread.run(Thread.java:680) > > Cheers, > > Stuart > > On 17 Oct 2012, at 09:15, Stuart Broad wrote: > >> Hi, >> >> I wanted to add that I am accessing the servlet via a javascript request >> from Apache HTTP. As such I am setting the following in the header of the >> POST response: >> >> resp.setHeader( "Access-Control-Allow-Origin", mAllowedHost ); >> >> Just wanted to mention this just in case it had anything to do with the >> init/param problem I am seeing. >> >> Cheers, >> >> Stuart >> >> On 16 Oct 2012, at 18:06, Stuart Broad wrote: >> >>> >>> Hi all, >>> >>> I am not sure why but my servlet init method is getting called more than >>> once and I am not sure why. Any help would be much appreciated. >>> >>> My web.xml is as follows: >>> >>> >>> >>> >>> myserlvet >>> MyServlet >>> true >>> >>> example >>> value >>> >>> 1 >>> >>> >>> >>> myservlet >>> /poll >>> /run >>> /stop >>> >>> >>> MySessionListener >>> >>> >>> >>> I am accessing over HTTPS. The initial POST seems to work ok: >>> >>> 0:0:0:0:0:0:0:1%0 - - [16/Oct/2012:16:53:54 +0100] "POST /myservlet/run >>> HTTP/1.1" 200 34 >>> >>> But then this is followed by a GET which fails: >>> >>> 0:0:0:0:0:0:0:1%0 - - [16/Oct/2012:16:53:54 +0100] "GET >>> /myservlet/poll?_dc=1350402834770 HTTP/1.1" 500 2312 >>> >>> The reason the GET fails is because the creation of the Servlet fails. >>> This is the second time the servlet init is called and for the second time >>> the init parameters are null (so
Re: asking advice for tomcat 7 config
On 17/10/2012 11:36, André Warnier wrote: > Mark Thomas wrote: >> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Connector_Comparison > Thanks. > Yes, I saw that table, but it is may be a bit "summarised" for the > average Tomcat user (or sysadmin). Is there somewhere a more > global/in-depth explanation of how this stuff all works ? > (request processing, thread allocation/deallocation etc., other than > snippets here and there related to the various connector attributes or > the source code comments ?) Not really. Like a lot of the Tomcat docs there is some assumed knowledge. In this case it is assumed that the reader understands the key differences between blocking and non-blocking IO, knows what polling is and what it all means for thread usage. I'm planning on talking about it at ApacheCon EU in a few weeks in my Tomcat and reverse proxies talk since to get the configuration right and avoid thread exhaustion you need to understand how all the moving parts use threads. I'll put the slides up in the usual place [1] once I have written them. Mark [1] http://people.apache.org/~markt/presentations/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: asking advice for tomcat 7 config
Mark Thomas wrote: On 17/10/2012 11:02, André Warnier wrote: Mark Thomas wrote: On 17/10/2012 10:49, André Warnier wrote: 1) So it means that if a client connects to the server, but does not send any request line for a while on that connection, the server will allocate a thread to serve the request; this thread will wait up to 20 s (on HTTP) or 60 s. (on HTTPS), before timing out and returning to the pool of available threads. Of course only a malicious client would do that.. Nope. This is the NIO connector. The request line is read using non-blocking IO. The (simulated) blocking IO only starts once the first header is received and continues until the entire request is received. It then goes back to non-blocking for the next request line. 2) it also means that a perfectly non-malicious client can connect to the server, and send a first request on the connection; the server will allocate a thread to handle this request; and then, if the same client has no more requests to send for a while, this thread will nevertheless remain waiting on this connection for 20 s. (HTTP) or 60 s. (HTTPS), just in case the client /would/ send another request on it. During this time, the thread is unavailable to process other client requests. Again, nope. The thread is released between the requests. Sorry, I stand corrected, I missed the NIO part. For the record, is the above correct for the standard BIO connector (and in part for the APR connector) ? BIO yes, the above is correct. NIO is actually non-blocker for the request headers as well. APR is is non-blocking between requests. See the summary chart at [1] for more. Mark [1] http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Connector_Comparison Thanks. Yes, I saw that table, but it is may be a bit "summarised" for the average Tomcat user (or sysadmin). Is there somewhere a more global/in-depth explanation of how this stuff all works ? (request processing, thread allocation/deallocation etc., other than snippets here and there related to the various connector attributes or the source code comments ?) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: asking advice for tomcat 7 config
On 17/10/2012 11:02, André Warnier wrote: > Mark Thomas wrote: >> On 17/10/2012 10:49, André Warnier wrote: >>> 1) So it means that if a client connects to the server, but does not >>> send any request line for a while on that connection, the server will >>> allocate a thread to serve the request; this thread will wait up to 20 s >>> (on HTTP) or 60 s. (on HTTPS), before timing out and returning to the >>> pool of available threads. >>> Of course only a malicious client would do that.. >> >> Nope. This is the NIO connector. The request line is read using >> non-blocking IO. The (simulated) blocking IO only starts once the first >> header is received and continues until the entire request is received. >> It then goes back to non-blocking for the next request line. >> >> >>> 2) it also means that a perfectly non-malicious client can connect to >>> the server, and send a first request on the connection; the server will >>> allocate a thread to handle this request; and then, if the same client >>> has no more requests to send for a while, this thread will nevertheless >>> remain waiting on this connection for 20 s. (HTTP) or 60 s. (HTTPS), >>> just in case the client /would/ send another request on it. >>> During this time, the thread is unavailable to process other client >>> requests. >> >> Again, nope. The thread is released between the requests. >> > > Sorry, I stand corrected, I missed the NIO part. > > For the record, is the above correct for the standard BIO connector > (and in part for the APR connector) ? BIO yes, the above is correct. NIO is actually non-blocker for the request headers as well. APR is is non-blocking between requests. See the summary chart at [1] for more. Mark [1] http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Connector_Comparison - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: asking advice for tomcat 7 config
>You've configured a separate pool for connectors on ports 80 and 443. Why? I thought it was better this way... Normally, the port 80 should automatically redirect to the port 443 and https only should be authorized. Is there any proper way to do that? >You've reduced the acceptCount to 50. Why? Oow ... I don't know ... tests. Do you suggest to raise it to a bigger value, such 200 or more? >You are compressing compressed images. Why? Compressing compressed images? Isn't compression="off" disabling that? >You are setting acceptorThreadCount=4. Why? Just test :) in the documentation it's written that 2 is a good number, but we can raise it to test, so did I and as it doesn't change anything, I left it. Do you suggest to put back 2? >Does your app have a database connection pool? Yes, but directly managed by the application with MyBatis. >What are the sizing parameters for this pool? But apparently, the database should not be the issue, as it runs on a separate server and when I check it, it never reaches that limits. --- >I will assume that you're not using APR/Native based on your SSL Connection >configuration. If you are using tcnative.dll, then the configuration for your >SSL connector will not work. I'm quite a newbie in tomcat tuning. That config came from an old application (tomcat 5) that uses the same SSL certificate, and apparently, it's working... > You've defined one Executor for each Connector. This is the default Tomcat > behavior, so I don't see where adding and using an Executor per Connector is > buying you anything. > In general, using an Executor pool allows you to share threads among several > Tomcat components. It's a nice way of managing resources and minimizing some > overhead. > acceptorThreadCount is set to 4. From the documentation, there doesn't seem > to be a need to set this above 2. > acceptCount is set to 50 (down from the default of 100). This means that the > total possible number of connections in your configuration is 1400 (2 x 650 + > 2 x 50). Any more requests will be refused. I'm not sure why you've reduced > the queue size. As you suggest, I will set back the first to 2 and the second to more than 100. I cannot say why it's less than the default behavior. Maybe because of some tests, or the old tomcat 5 config... > 1. Remove the Executors > 2. Set the Connector elements back to their factory settings > 3. add acceptorThreadCount="2" since you have a multi-core CPU > 4. add SSL configuration pertaining to your environment > 5. you may want to add URIEncoding="UTF-8" depending on your web app Ok, I'll do that. > Then, attach VisualVM on the local machine to profile. VisualVM running > remotely for profiling doesn't work too well. That's already the case :) > Finally, use a separate machine (preferably Linux) to run JMeter. That's also already the case, but a Windows 7 one. I will launch my next tests on a linux computer as you suggest. > Since you mentioned oracle.net.ns.Packet.receive(), I suspect that you're > using an Oracle database, and your web application is database - intensive. > As Pid has mentioned, how do you manage your database connections? Everything is on top of this mail :-) > Once you have isolated and addressed your application performance issues, you > can then start looking at Tomcat parameters to improve performance. > . . . . just my two cents. Every help is good to take, and thanks to all of you :-) I make the changes, re-run the tests and let you know the results. Romain. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: asking advice for tomcat 7 config
Mark Thomas wrote: On 17/10/2012 10:49, André Warnier wrote: 1) So it means that if a client connects to the server, but does not send any request line for a while on that connection, the server will allocate a thread to serve the request; this thread will wait up to 20 s (on HTTP) or 60 s. (on HTTPS), before timing out and returning to the pool of available threads. Of course only a malicious client would do that.. Nope. This is the NIO connector. The request line is read using non-blocking IO. The (simulated) blocking IO only starts once the first header is received and continues until the entire request is received. It then goes back to non-blocking for the next request line. 2) it also means that a perfectly non-malicious client can connect to the server, and send a first request on the connection; the server will allocate a thread to handle this request; and then, if the same client has no more requests to send for a while, this thread will nevertheless remain waiting on this connection for 20 s. (HTTP) or 60 s. (HTTPS), just in case the client /would/ send another request on it. During this time, the thread is unavailable to process other client requests. Again, nope. The thread is released between the requests. Sorry, I stand corrected, I missed the NIO part. For the record, is the above correct for the standard BIO connector (and in part for the APR connector) ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: asking advice for tomcat 7 config
On 17/10/2012 10:49, André Warnier wrote: > 1) So it means that if a client connects to the server, but does not > send any request line for a while on that connection, the server will > allocate a thread to serve the request; this thread will wait up to 20 s > (on HTTP) or 60 s. (on HTTPS), before timing out and returning to the > pool of available threads. > Of course only a malicious client would do that.. Nope. This is the NIO connector. The request line is read using non-blocking IO. The (simulated) blocking IO only starts once the first header is received and continues until the entire request is received. It then goes back to non-blocking for the next request line. > 2) it also means that a perfectly non-malicious client can connect to > the server, and send a first request on the connection; the server will > allocate a thread to handle this request; and then, if the same client > has no more requests to send for a while, this thread will nevertheless > remain waiting on this connection for 20 s. (HTTP) or 60 s. (HTTPS), > just in case the client /would/ send another request on it. > During this time, the thread is unavailable to process other client > requests. Again, nope. The thread is released between the requests. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: asking advice for tomcat 7 config
Pid wrote: ... connectionTimeout="2" redirectPort="443" server="lighthttpd/2.0.0" enableLookups="false" acceptorThreadCount="4" socket.directBuffer="false" compression="off" compressableMimeType="text/html,text/xml,text/plain,text/javascript,text/css,image/jpeg,image/png,image/gif" acceptCount="50" bufferSize="4096" /> You've configured a separate pool for connectors on ports 80 and 443. Why? You've reduced the acceptCount to 50. Why? You are compressing compressed images. Why? There is : compression="off" in both connectors though. So I guess that compressableMimeType should be ignored. (It /is/ still questionable to have changed the default of compressableMimeType, to include types which are inherently compressed already.) You are setting acceptorThreadCount=4. Why? Does your app have a database connection pool? What are the sizing parameters for this pool? Also, - for the HTTP connector, connectionTimeout is set to 2 (milliseconds), and keepAliveTimeout is not set. - for the HTTPS connector, neither one is set. That will cause : - for the HTTP connector : - connectionTimeout = 2 ms (20 s.) - keepAliveTimeout = 2 ms - for the HTTPS connector : - connectionTimeout = 6 ms (60 s.) - keepAliveTimeout = 6 ms 1) So it means that if a client connects to the server, but does not send any request line for a while on that connection, the server will allocate a thread to serve the request; this thread will wait up to 20 s (on HTTP) or 60 s. (on HTTPS), before timing out and returning to the pool of available threads. Of course only a malicious client would do that.. 2) it also means that a perfectly non-malicious client can connect to the server, and send a first request on the connection; the server will allocate a thread to handle this request; and then, if the same client has no more requests to send for a while, this thread will nevertheless remain waiting on this connection for 20 s. (HTTP) or 60 s. (HTTPS), just in case the client /would/ send another request on it. During this time, the thread is unavailable to process other client requests. Discarding item (1) for now as being a DOS attack, might (2) not go a long way to explain the symtoms that the OP is mentioning ? I would try setting : - for the HTTP connector : - connectionTimeout = 5000 ms (5 s.) - keepAliveTimeout = 5000 ms - for the HTTPS connector : - connectionTimeout = 5000 ms (5 s.) - keepAliveTimeout = 5000 ms on the premises that : - a genuine well-intentioned client is very unlikely to establish a connection with a webserver, and then not send any request on that connection for all of 5 seconds - if a client, after making a first request and having obtained the response to it, is then not making any further request to the server on the same connection for more than 5 seconds, it probably means that he has for now nothing more to request. And it is not the overhead of establishing a new TCP connection later that is nowadays going to penalise the client or the server. And this would allow these Tomcat threads to be recycled much faster, instead of just sitting there doing nothing. Is that analysis wrong ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: asking advice for tomcat 7 config
On 10/17/2012 1:28 AM, Mark Thomas wrote: On 17/10/2012 07:59, Romain Van der Keilen wrote: Hi There, I'm quiet new to this mailing list as I encounter some configuration problems with Tomcat 7.0.30. It is unlikely to help but you may as well upgrade to 7.0.32. We are currently developing a web application, and we wish to have a good response time with about 200 parallel sessions. My problem is that starting from 70 users, the system does not respond quietly. At 70 users, we have an average of 4000ms for the response time. At 120 users we are at an average of 2ms and with 200 users we have about 45000ms of response time. All of those numbers were computed with JMeter, using 4 passes. I have seen very strange results with JMeter under load, particularly on Windows. The results you are seeing may not be entirely correct. I get better results (although less control) with ab on Windows. Or I run JMeter on Linux. When the server is under a big load, what I could see with VisualVM is that the heap size used never exceed 500Mb. When 500Mb is reached, it drops back to about 100Mb. Another thing is that the CPU never works more than 5% of its capabilities. That suggests that the app is not CPU bound. I also took a look at the CPU usage in java classes, Using what> and there I saw that 95% of the time goes to org.apache.tomcat.util.threads.TaskQueue.take(). That is normal and means for 95% of the total thread processing time, threads are waiting for the next task to process. It is the other 5% you want to concentrate on. The first class related to my application is the oracle.net.ns.Packet.receive() and is at 0.1% of the CPU time ... I've looked on a lot of forums to try to tune my tomcat configuration, but I haven't found anything that could really help me, this is the reason I ask to you. I've just put you the whole server.xml file after this, hoping you can have a look and tell me if there is some big issue with it... The only thing I changed is the IP of the server. Profiling is the way to go to fix this and it looks like you are heading in the right direction however you may need some better tools. Mark I'll fold in some of Pid's comments as well. It's a bit late and I've not explored this particular environment before. However, I'll attempt to make some comments based on your configuration. I've taken the liberty in reformatting a portion of your configuration so I could find things more easily. I will assume that you're not using APR/Native based on your SSL Connection configuration. If you are using tcnative.dll, then the configuration for your SSL connector will not work. You've defined one Executor for each Connector. This is the default Tomcat behavior, so I don't see where adding and using an Executor per Connector is buying you anything. In general, using an Executor pool allows you to share threads among several Tomcat components. It's a nice way of managing resources and minimizing some overhead. On your Connector elements, a few things stand out. The protocol that you've chosen can accept up to 1 requests. However you've limited this to 650 by the use of the Executor element. acceptorThreadCount is set to 4. From the documentation, there doesn't seem to be a need to set this above 2. acceptCount is set to 50 (down from the default of 100). This means that the total possible number of connections in your configuration is 1400 (2 x 650 + 2 x 50). Any more requests will be refused. I'm not sure why you've reduced the queue size. I don't understand your compression configuration setup. You've set compression to off, but then you set compressibleMineTypes? I'm also not sure if the Connector will compress non-text MIME types even when told to (need to look at the code). This is especially confusing for image MIME types that are already compressed. Finally, bufferSize does not seem to be an attribute for Tomcat 7. This did exist in Tomcat 6. My immediate thoughts are to do the following: 1. Remove the Executors 2. Set the Connector elements back to their factory settings 3. add acceptorThreadCount="2" since you have a multi-core CPU 4. add SSL configuration pertaining to your environment 5. you may want to add URIEncoding="UTF-8" depending on your web app Then, attach VisualVM on the local machine to profile. VisualVM running remotely for profiling doesn't work too well. Finally, use a separate machine (preferably Linux) to run JMeter. Since you mentioned oracle.net.ns.Packet.receive(), I suspect that you're using an Oracle database, and your web application is database - intensive. As Pid has mentioned, how do you manage your database connections? 1. Do you use connection pooling? 2. Is the connection pooling Tomcat-controlled? 3. What is the configuration Once you have isolated and addressed your application performance issues, you can then start looking at Tomcat parameters to improve performance. . . .
Re: Servlet init method called twice (2nd time with null init params)
Hi, Sorry to keep replying to my own question but I gathered two stack traces from each of the calls to init that may be useful: On startup (and this is the servlet also used by the post): at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1266) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1185) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1080) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5027) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5314) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:618) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:963) at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1600) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) On calling get (this is the one that fails and has no init-param information): at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1266) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1185) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:857) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1001) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Cheers, Stuart On 17 Oct 2012, at 09:15, Stuart Broad wrote: > Hi, > > I wanted to add that I am accessing the servlet via a javascript request from > Apache HTTP. As such I am setting the following in the header of the POST > response: > > resp.setHeader( "Access-Control-Allow-Origin", mAllowedHost ); > > Just wanted to mention this just in case it had anything to do with the > init/param problem I am seeing. > > Cheers, > > Stuart > > On 16 Oct 2012, at 18:06, Stuart Broad wrote: > >> >> Hi all, >> >> I am not sure why but my servlet init method is getting called more than >> once and I am not sure why. Any help would be much appreciated. >> >> My web.xml is as follows: >> >> >> >> >> myserlvet >> MyServlet >> true >> >> example >> value >> >> 1 >> >> >> >> myservlet >> /poll >> /run >> /stop >> >> >> MySessionListener >> >> >> >> I am accessing over HTTPS. The initial POST seems to work ok: >> >> 0:0:0:0:0:0:0:1%0 - - [16/Oct/2012:16:53:54 +0100] "POST /myservlet/run >> HTTP/1.1" 200 34 >> >> But then this is followed by a GET which fails: >> >> 0:0:0:0:0:0:0:1%0 - - [16/Oct/2012:16:53:54 +0100] "GET >> /myservlet/poll?_dc=1350402834770 HTTP/1.1" 500 2312 >> >> The reason the GET fails is because the creation of the Servlet fails. This >> is the second time the servlet init is called and for the second time the >> init parameters are null (so it fails to be created). If I could figure out >> why the init params are null the second time around I could probably come up >> with a work around BUT my preference is to figure out why the init method is >> being called twice. >> >> I bit more information: >> >> Tomcat version: apache-tomcat-7.0.29 >> Mac OS X 10.7.5 >> >>
Re: asking advice for tomcat 7 config
On 17/10/2012 08:59, Romain Van der Keilen wrote: > Hi There, > > I'm quiet new to this mailing list as I encounter some configuration problems > with Tomcat 7.0.30. > We are currently developing a web application, and we wish to have a good > response time with about 200 parallel sessions. My problem is that starting > from 70 users, the system does not respond quietly. At 70 users, we have an > average of 4000ms for the response time. At 120 users we are at an average of > 2ms and with 200 users we have about 45000ms of response time. All of > those numbers were computed with JMeter, using 4 passes. > > Tomcat is running with the following options: jdk 1.7.0_07 ; server\jvm.dll ; > initial memory pool 1024Mb ; maximum memory pool 1250 Mb ; Thread stack size > : 1024 kb ; 64 bit version for both java and tomcat > The server itself is a Windows Server 2008 Standard edition running on Intel > Xeon X5660 @ 2.8Ghz (2 physical processors ; 24 virtual processors ) ; 12Gb > Ram > > When the server is under a big load, what I could see with VisualVM is that > the heap size used never exceed 500Mb. When 500Mb is reached, it drops back > to about 100Mb. Another thing is that the CPU never works more than 5% of its > capabilities. > I also took a look at the CPU usage in java classes, and there I saw that 95% > of the time goes to org.apache.tomcat.util.threads.TaskQueue.take(). The > first class related to my application is the oracle.net.ns.Packet.receive() > and is at 0.1% of the CPU time ... > > I've looked on a lot of forums to try to tune my tomcat configuration, but I > haven't found anything that could really help me, this is the reason I ask to > you. I've just put you the whole server.xml file after this, hoping you can > have a look and tell me if there is some big issue with it... The only thing > I changed is the IP of the server. > > Thanks in advance, > > Romain Van der Keilen. > > > > > > >SSLEngine="on" /> > > > >className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> > >className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /> >className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" /> > > >type="org.apache.catalina.UserDatabase" > description="User database that can be updated and saved" > factory="org.apache.catalina.users.MemoryUserDatabaseFactory" > pathname="conf/tomcat-users.xml" /> > > > > >maxThreads="650" minSpareThreads="100" /> >maxHttpHeaderSize="8192" protocol="org.apache.coyote.http11.Http11NioProtocol" >connectionTimeout="2" redirectPort="443" > server="lighthttpd/2.0.0" enableLookups="false" acceptorThreadCount="4" > socket.directBuffer="false" > compression="off" > compressableMimeType="text/html,text/xml,text/plain,text/javascript,text/css,image/jpeg,image/png,image/gif" > acceptCount="50" bufferSize="4096" /> > > >maxThreads="650" minSpareThreads="100" /> > protocol="org.apache.coyote.http11.Http11NioProtocol" port="443" > SSLEnabled="true" scheme="https" secure="true" > clientAuth="false" sslProtocol="TLS" > keystoreFile="D:\keystore\appks" server="lighthttpd/2.0.0" > enableLookups="false" keystorePass="changeit" > address="10.10.10.10" acceptorThreadCount="4" socket.directBuffer="false" > compression="off" > compressableMimeType="text/html,text/xml,text/plain,text/javascript,text/css,image/jpeg,image/png,image/gif" > acceptCount="50" bufferSize="4096" > > You've configured a separate pool for connectors on ports 80 and 443. Why? You've reduced the acceptCount to 50. Why? You are compressing compressed images. Why? You are setting acceptorThreadCount=4. Why? Does your app have a database connection pool? What are the sizing parameters for this pool? p > > >resourceName="UserDatabase"/> > >autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false"> >className="org.apache.catalina.valves.AccessLogValve" > directory="D:\Logfiles\Tomcat\http\Prod" prefix="access_log." suffix=".txt" > pattern="common"/> >crossContext="false"> > > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: asking advice for tomcat 7 config
On 17/10/2012 07:59, Romain Van der Keilen wrote: > Hi There, > > I'm quiet new to this mailing list as I encounter some configuration > problems with Tomcat 7.0.30. It is unlikely to help but you may as well upgrade to 7.0.32. > We are currently developing a web > application, and we wish to have a good response time with about 200 > parallel sessions. My problem is that starting from 70 users, the > system does not respond quietly. At 70 users, we have an average of > 4000ms for the response time. At 120 users we are at an average of > 2ms and with 200 users we have about 45000ms of response time. > All of those numbers were computed with JMeter, using 4 passes. I have seen very strange results with JMeter under load, particularly on Windows. The results you are seeing may not be entirely correct. I get better results (although less control) with ab on Windows. Or I run JMeter on Linux. > When the server is under a big load, what I could see with VisualVM > is that the heap size used never exceed 500Mb. When 500Mb is reached, > it drops back to about 100Mb. Another thing is that the CPU never > works more than 5% of its capabilities. That suggests that the app is not CPU bound. > I also took a look at the CPU > usage in java classes, Using what> > and there I saw that 95% of the time goes to > org.apache.tomcat.util.threads.TaskQueue.take(). That is normal and means for 95% of the total thread processing time, threads are waiting for the next task to process. It is the other 5% you want to concentrate on. > The first class > related to my application is the oracle.net.ns.Packet.receive() and > is at 0.1% of the CPU time ... > > I've looked on a lot of forums to try to tune my tomcat > configuration, but I haven't found anything that could really help > me, this is the reason I ask to you. I've just put you the whole > server.xml file after this, hoping you can have a look and tell me if > there is some big issue with it... The only thing I changed is the IP > of the server. Profiling is the way to go to fix this and it looks like you are heading in the right direction however you may need some better tools. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Servlet init method called twice (2nd time with null init params)
Hi, I wanted to add that I am accessing the servlet via a javascript request from Apache HTTP. As such I am setting the following in the header of the POST response: resp.setHeader( "Access-Control-Allow-Origin", mAllowedHost ); Just wanted to mention this just in case it had anything to do with the init/param problem I am seeing. Cheers, Stuart On 16 Oct 2012, at 18:06, Stuart Broad wrote: > > Hi all, > > I am not sure why but my servlet init method is getting called more than once > and I am not sure why. Any help would be much appreciated. > > My web.xml is as follows: > > > > >myserlvet >MyServlet >true > >example >value > >1 > > > >myservlet >/poll >/run >/stop > > > MySessionListener > > > > I am accessing over HTTPS. The initial POST seems to work ok: > > 0:0:0:0:0:0:0:1%0 - - [16/Oct/2012:16:53:54 +0100] "POST /myservlet/run > HTTP/1.1" 200 34 > > But then this is followed by a GET which fails: > > 0:0:0:0:0:0:0:1%0 - - [16/Oct/2012:16:53:54 +0100] "GET > /myservlet/poll?_dc=1350402834770 HTTP/1.1" 500 2312 > > The reason the GET fails is because the creation of the Servlet fails. This > is the second time the servlet init is called and for the second time the > init parameters are null (so it fails to be created). If I could figure out > why the init params are null the second time around I could probably come up > with a work around BUT my preference is to figure out why the init method is > being called twice. > > I bit more information: > > Tomcat version: apache-tomcat-7.0.29 > Mac OS X 10.7.5 > > Cheers, > > Stuart > - > 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: asking advice for tomcat 7 config
I have faced similar issues as well! I have quite similar tomcat6 over a similar hardware infrastructure and sometimes we noticed some unavailable issues as well! I already tried tuning tomcat but not success! The only thing I did last time was increase the maxthread from 200 to 500 and another tip I got here was for to take some thread dumps. Did you already do that? Tks Sent from my iPhone On 17/10/2012, at 03:59, Romain Van der Keilen wrote: > Hi There, > > I'm quiet new to this mailing list as I encounter some configuration problems > with Tomcat 7.0.30. > We are currently developing a web application, and we wish to have a good > response time with about 200 parallel sessions. My problem is that starting > from 70 users, the system does not respond quietly. At 70 users, we have an > average of 4000ms for the response time. At 120 users we are at an average of > 2ms and with 200 users we have about 45000ms of response time. All of > those numbers were computed with JMeter, using 4 passes. > > Tomcat is running with the following options: jdk 1.7.0_07 ; server\jvm.dll ; > initial memory pool 1024Mb ; maximum memory pool 1250 Mb ; Thread stack size > : 1024 kb ; 64 bit version for both java and tomcat > The server itself is a Windows Server 2008 Standard edition running on Intel > Xeon X5660 @ 2.8Ghz (2 physical processors ; 24 virtual processors ) ; 12Gb > Ram > > When the server is under a big load, what I could see with VisualVM is that > the heap size used never exceed 500Mb. When 500Mb is reached, it drops back > to about 100Mb. Another thing is that the CPU never works more than 5% of its > capabilities. > I also took a look at the CPU usage in java classes, and there I saw that 95% > of the time goes to org.apache.tomcat.util.threads.TaskQueue.take(). The > first class related to my application is the oracle.net.ns.Packet.receive() > and is at 0.1% of the CPU time ... > > I've looked on a lot of forums to try to tune my tomcat configuration, but I > haven't found anything that could really help me, this is the reason I ask to > you. I've just put you the whole server.xml file after this, hoping you can > have a look and tell me if there is some big issue with it... The only thing > I changed is the IP of the server. > > Thanks in advance, > > Romain Van der Keilen. > > > > > > > SSLEngine="on" /> > > > > className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> > > className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /> > className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" /> > > > type="org.apache.catalina.UserDatabase" > description="User database that can be updated and saved" > factory="org.apache.catalina.users.MemoryUserDatabaseFactory" > pathname="conf/tomcat-users.xml" /> > > > > > maxThreads="650" minSpareThreads="100" /> > maxHttpHeaderSize="8192" protocol="org.apache.coyote.http11.Http11NioProtocol" > connectionTimeout="2" redirectPort="443" > server="lighthttpd/2.0.0" enableLookups="false" acceptorThreadCount="4" > socket.directBuffer="false" > compression="off" > compressableMimeType="text/html,text/xml,text/plain,text/javascript,text/css,image/jpeg,image/png,image/gif" > acceptCount="50" bufferSize="4096" /> > > > maxThreads="650" minSpareThreads="100" /> > protocol="org.apache.coyote.http11.Http11NioProtocol" port="443" > SSLEnabled="true" scheme="https" secure="true" >clientAuth="false" sslProtocol="TLS" keystoreFile="D:\keystore\appks" > server="lighthttpd/2.0.0" >enableLookups="false" keystorePass="changeit" address="10.10.10.10" > acceptorThreadCount="4" socket.directBuffer="false" >compression="off" > compressableMimeType="text/html,text/xml,text/plain,text/javascript,text/css,image/jpeg,image/png,image/gif" >acceptCount="50" bufferSize="4096" > > > > > > resourceName="UserDatabase"/> > > autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false"> > directory="D:\Logfiles\Tomcat\http\Prod" prefix="access_log." suffix=".txt" > pattern="common"/> > crossContext="false"> > > > > > > > > - > 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: FAIL - Application at context path /test could not be started
On 16.10.2012, at 15:26, majin_clo...@t-online.de wrote: > Thanks for your reply. :) > > my web.xml looks like this: > > > http://java.sun.com/xml/ns/javaee"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee > http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd";> > > > > org.test.web.servlets.BigBangServletContextListener > > >> Oct 16, 2012 12:46:47 PM org.apache.catalina.startup.HostConfig >> deployWAR >> INFO: Deploying web application archive test.war >> Oct 16, 2012 12:46:47 PM > org.apache.catalina.loader.WebappClassLoader >> validateJarFile >> INFO: >> validateJarFile(/var/lib/tomcat6/webapps/test/WEB-INF/lib/servlet-api-2.5-6.1.14.jar) >> - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending >> class: javax/servlet/Servlet.class You must not include the servlet API as .jar in your web app. It is provided by the container. Remove this file. This is not your problem though - as the message says, it is not loaded. >> SEVERE: Error listenerStart This means the listener defined above (org.test.web.servlets.BigBangServletContextListener) does not start. Either that class is not found, it does not implement the ServletContextListener interface or it fails to initialize internally. Maybe other log files have more info, or s.o. else knows more details on how these cases are distinguished - or even better just verify all three possibilities yourself Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
asking advice for tomcat 7 config
Hi There, I'm quiet new to this mailing list as I encounter some configuration problems with Tomcat 7.0.30. We are currently developing a web application, and we wish to have a good response time with about 200 parallel sessions. My problem is that starting from 70 users, the system does not respond quietly. At 70 users, we have an average of 4000ms for the response time. At 120 users we are at an average of 2ms and with 200 users we have about 45000ms of response time. All of those numbers were computed with JMeter, using 4 passes. Tomcat is running with the following options: jdk 1.7.0_07 ; server\jvm.dll ; initial memory pool 1024Mb ; maximum memory pool 1250 Mb ; Thread stack size : 1024 kb ; 64 bit version for both java and tomcat The server itself is a Windows Server 2008 Standard edition running on Intel Xeon X5660 @ 2.8Ghz (2 physical processors ; 24 virtual processors ) ; 12Gb Ram When the server is under a big load, what I could see with VisualVM is that the heap size used never exceed 500Mb. When 500Mb is reached, it drops back to about 100Mb. Another thing is that the CPU never works more than 5% of its capabilities. I also took a look at the CPU usage in java classes, and there I saw that 95% of the time goes to org.apache.tomcat.util.threads.TaskQueue.take(). The first class related to my application is the oracle.net.ns.Packet.receive() and is at 0.1% of the CPU time ... I've looked on a lot of forums to try to tune my tomcat configuration, but I haven't found anything that could really help me, this is the reason I ask to you. I've just put you the whole server.xml file after this, hoping you can have a look and tell me if there is some big issue with it... The only thing I changed is the IP of the server. Thanks in advance, Romain Van der Keilen. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
