Re: Unrecognized VM option '+HeapDumpOnCtrlBreak'
That option is not available in Java 6. With Java 6, you can use jmap to take a heap dump. Bill On Thu, Jun 3, 2010 at 9:12 AM, Kaushal Shriyan kaushalshri...@gmail.comwrote: Hi, I am running tomcat 5.5.27 on ubuntu 8.04, java version is java -version java version 1.6.0_06 Java(TM) SE Runtime Environment (build 1.6.0_06-b02) Java HotSpot(TM) 64-Bit Server VM (build 10.0-b22, mixed mode) I did added JAVA_OPTS=-Xms512m -Xmx4500m -XX:+HeapDumpOnCtrlBreak -XX:+HeapDumpOnOutOfMemoryError on tomcat init script Unrecognized VM option '+HeapDumpOnCtrlBreak' Could not create the Java virtual machine. done. Please suggest Thanks, Kaushal
Re: Prevent JSP Session
I an actually facing the same situation. Is it possible to disable JSP sessions once and for all with a configuration setting? Adding the page directive to disable session to each JSP should work but I am afraid that our developers will not always remember to do so. Bill On Wed, May 19, 2010 at 9:24 AM, Brett Birschbach brett.birschb...@hs2solutions.com wrote: Always happens...as soon as I ask the question, I figure out the answer. The problem is I am running c:import tags to import some JSPs, and those imported JSPs do not have the %@ page session=false % directive. If I add the directive to those JSPs, I'm golden. -- Brett Birschbach HS2 Solutions, Inc brett.birschb...@hs2solutions.com (773) 296-2600 x501 -Original Message- From: Brett Birschbach [mailto:brett.birschb...@hs2solutions.com] Sent: Wednesday, May 19, 2010 8:16 AM To: users@tomcat.apache.org Subject: Prevent JSP Session I am currently running Tomcat 6.0.24 on a Windows Vista machine. The web app I am developing will be deployed to a cloud, where server affinity will be thrown to the wind. Thus, instead of relying on tomcat to manage my session, I am instead managing the session via manual cookies and a database. Being that I cannot leverage the tomcat session, I don't want to create a session at all. This has a two-fold benefit: 1) Slight performance increase due to avoiding session creation overhead 2) I can put a session listener in place to log an error if ever a session is created, to ensure that we are not using the tomcat session in the development environment where everything would appear to be fine until we deploy to the cloud. According to JSP spec, I believe I should be able to use the following directive to prevent a session from being created by my JSPs: %@ page session=false %. However, even when doing so, I am still getting a session created by the internals of the JSP container. Is there something I am doing wrong? Is it possibly a bug in Tomcat 6.0.24 (couldn't find it on Bugzilla)? Or is it simply a necessary evil? The generated JSP code that is triggering the session is: pageContext = _jspxFactory.getPageContext(this, request, response, null, true, 8192, true); Below is the relevant portion of an exact stack trace: at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:854) at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291) at org.apache.catalina.connector.Request.doGetSession(Request.java:2392) at org.apache.catalina.connector.Request.getSession(Request.java:2098) at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833) at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216) at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:544) at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:493) at org.apache.jasper.runtime.PageContextImpl._initialize(PageContextImpl.java:146) at org.apache.jasper.runtime.PageContextImpl.initialize(PageContextImpl.java:124) at org.apache.jasper.runtime.JspFactoryImpl.internalGetPageContext(JspFactoryImpl.java:107) at org.apache.jasper.runtime.JspFactoryImpl.getPageContext(JspFactoryImpl.java:63) at org.apache.jsp.layouts.nav.layout_005fnav_002dadmin_jsp._jspService(layout_005fnav_002dadmin_jsp.java:44) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) Thanks! -- Brett Birschbach HS2 Solutions, Inc brett.birschb...@hs2solutions.com - 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
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
Re: question about APR based native library
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. 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. 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
Re: Tomcat - All threads (200) are currently busy
Take a thread dump of the JVM: http://java.sun.com/developer/technicalArticles/Programming/Stacktrace/ Bill On 7/12/07, André Vila Cova [EMAIL PROTECTED] wrote: Hi! I've this two processes: tomcat6404 0.0 2.6 484396 105456 ? Sl 01:05 0:14 /usr/local/java1.5/bin/java -Xms64m -Xmx200m -Xss512k - Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager - Djava.util.logging.conf tomcat6555 0.1 3.8 516420 154452 ? Sl 01:09 0:39 /usr/local/java1.5/bin/java -Xms64m -Xmx200m -Xss512k - Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager - Djava.util.logging.conf Output is null when I execute the following command: [EMAIL PROTECTED] ~]# kill -QUIT 6404 [EMAIL PROTECTED] ~]# How can I see what thread is doing? Thank You On 7/11/07, Titi Wangsa [EMAIL PROTECTED] wrote: probably some threads are performing database operation and it takes too long so new threads are being spawned, the new threads are also taking too long, so newer threads are being spawned. too much spawning, that is what is causing the limit break. On 7/12/07, André Vila Cova [EMAIL PROTECTED] wrote: I don't think so... I will see..but, why i get the error? SEVERE: All threads (200) are currently *busy*, waiting. *Increase On 7/11/07, Mladen Turk [EMAIL PROTECTED] wrote: André Vila Cova wrote: Hello! I get lot of times the following error: SEVERE: All threads (200) are currently *busy*, waiting. *Increase maxThreads* ** *Strange is that i've configured in server.xml the following (maxThreads=400):* * You have probably done that for a wrong connector. Regards, Mladen. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can servlets safely spawn threads?
If you are spawning threads from your servlet, make sure that they are cleaned up when the servlet is destroyed. Otherwise, you will have a thread leak. I have ran into this problem when the webapp is reloaded without restarting the server. Each leaked thread has a reference to its classloader, preventing that classloader from being garbage collected. Reload enough time will run the perm space out of memory. Bill On 1/29/07, Christopher Schultz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Danny, David Delbecq wrote: 1) Your servlet must always take care to finish all Threads it has spawned. This mean when servlet gets unloaded, you must have provided a mecanism in your servlet to stop all running threads your servlet has created. Remaining Threads not handled by container can either cause tomcat to not stop when requested or prevent garbage collecting of webapp when reloading. Consider using an existing thread pool component. It should have a graceful shutdown capability already built into it. David is right: you have to make sure to shut it down when appropriate. In general, try to avoid spawning your own thread. I agree, which is why I recommend using a thread pool. Yes, you are still technically spawning your own threads (the container will not do it for you), but the point is that you will not be spawning a thread for each request. Set up your thread pool to have a reasonable number of threads for your application. You do not want to have loads of users submit jobs that will each spawn a new thread. If you run out of threads in the thread pool, you simply tell the user to come back later. Management of this type of resource is essential to maintaining a stable and useful system. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFvgK+9CaO5/Lv0PARAoIFAJ45DgOyFV9qxS2e+Qt9uHNTtkWpywCdHbnq pltJVjDsmhZMg0143155k7M= =pbEp -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
