Re: Ideal way to minimize resources used by Tomcat for sessions
2012/11/19 Baron Von Awsm baronvona...@gmail.com: My web app consists of a single servlet, no JSPs and no static content. The servlet retrieves XML from POST submissions and hands the XML and IP address of the client to an API/engine. This engine can work outside of a web container and has no knowledge of a web container. It has its own mechanism for managing sessions. For this reason, for this web application, I require no session management overhead by Tomcat. I would like to disable all aspects (that I can) of Tomcat session management, including session cookies and/or url rewriting. Searches on the topic yielded the following suggestions, 1. Never call getSession(). That makes sense - if its never called then things are never stored in the session and, perhaps, Tomcat doesn't create some things that it might have. +1. Unless you call getSession() or getSession(true) no new session is created. (There is a small number of components, such as FormAuthenticator, that will create a session, but all them are off by default). Note that you can implement a javax.servlet.http.HttpSessionListener (like the one in the examples webapp). Its sessionCreated() method will be called whenever a session is created in your webapp. If there is no session, no urlrewriting happens. The set-cookie response header is sent only when a new session is created. Regarding some processing of incoming cookie header, I think it will be parsed, but I am sure that its value is not used unless getSession(false) is called (which causes a lookup of an existing session using that ID). You should be able to ignore that overhead. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Modify Cache-Control header
2012/11/18 Terence M. Bandoian tere...@tmbsw.com: On 11/16/2012 2:38 PM, Jose María Zaragoza wrote: Hi: I'm using Tomcat 6 ( I don't remember the exact release, I hope to be forgiven by Pid ) I need to modify Cache-Control header in some responses ( forcing them to not be cached ) What is the best way to do it ? a) To implement a Valve ( check request context path and if it match ,to modify response header ) b) To implement a filter c) Others ( any property in Tomcat's configuration files that I don't know ) Thanks and regards Hi, Jose- If you have access to the JSP or Java, you might use something like this: response.setHeader( Expires, -1 ); response.setHeader( Cache-Control, no-cache ); See http://docs.oracle.com/javaee/6/api/index.html?javax/servlet/http/HttpServletResponse.html +1. UrlRewriteFilter can be used to set headers, if you do not want to write the code by yourself. http://wiki.apache.org/tomcat/AddOns ExpiresFilter is available in Tomcat 7 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form based login authentication
On 10/11/12 17:47, Russ Kepler wrote: On Saturday, November 10, 2012 05:14:43 PM you wrote: I thought it would helpful to let you know that I am very nearly ready to submitting a lot of new unit tests for the FormAuthenticator class. The new tests explore url path extensions to carry the sessionid in the absence of cookies. I have a couple of cases left to develop, which are closely related to your situation. If you are not in too much hurry, then I suggest you wait for me, rather than waste time developing a demonstration war... I'll get back to you later this week if I need any more information about your problem, or even if I think you are just experiencing a that's just the way it works situation (at the moment I am not sure). Brian, Thanks for the post, good to hear that my post hasn't been lost. I do have a cheap test in a .war, attached. All it does is to try and get through the form login. Form login works with cookie sessions but fails with URL sessions. I've left commented out all the attempts to get past this in login.jsp and in other files. I really think the form login with URL validation got broken recently. I've not been able to make it work with 7.0.32 but think it was working with an earlier revision. I suspect that the combination of invalidating the original session and creating a new one combined with losing the original requested URL forces folks to simply cycle through j_security_check - if login fails it goes to the error handler, if I pass it fails with a 408 because it's lost the original URL. The same logic works when I change the tracking-mode from URL to COOKIE; leading me to believe that I have things setup and it's some breakage in authentication. server.xml: Realm className=org.apache.catalina.realm.LockOutRealm !-- This Realm uses the UserDatabase configured in the global JNDI resources under the key UserDatabase. Any edits that are performed against this UserDatabase are immediately available for use by the Realm. -- Realm className=org.apache.catalina.realm.UserDatabaseRealm resourceName=UserDatabase/ /Realm web.xml session-config session-timeout30/session-timeout tracking-modeURL/tracking-mode !-- tracking-modeCOOKIE/tracking-mode -- /session-config tomcat-users.xml: tomcat-users role rolename=webtyper/ user username=webtyper password=webtyper roles=webtyper/ /tomcat-users Russ, Sorry about the delay. I started to look at your demo war. Tomcat builds with a standard user and role, so I decided to open your war and edit your web.xml to use tomcat/tomcat. I noticed that you have only one security constraint: security-constraint web-resource-collection web-resource-nameTyper/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-nametomcat/role-name /auth-constraint /security-constraint That didn't look right to me, because you also have: login-config auth-methodFORM/auth-method form-login-config form-login-page/logon.jsp/form-login-page form-error-page/logonError.jsp/form-error-page /form-login-config /login-config I /thought/ that meant an unauthenticated user does not have permission to access your logon.jsp or logonError.jsp files. I have always included an explicit allow unauthenticated users security constraint for those pages in my own web.xml files. HOWEVER, I WAS WRONG! When I followed your webapp through the FormAuthenticator I discovered the forwardToLoginPage and forwardToErrorPage methods do not make any reference to the security constraints for the webapp. i.e. the form-login-config pages are automatically accessible to unauthenticated users. (Thanks for giving me the opportunity to learn something new!) Once I had your with-cookies demo working properly, I then added the session-config section with a tracking-mode of URL to your web.xml. I was lazy and didn't use a stable tomcat release - I just ran it under my current version of the trunk, which is deliberately a couple of weeks back-level. I was very surprised to find that pressing the submit button with a good username and password threw the browser out with a connection reset! I little bit of debugging and I discovered that authentication was looping - each time j_security_check authenticated ok, but the session created by the original HTTP GET to your protected resource was not being recovered from the cache. The line in your logon.jsp: form action=j_security_check method=post ... was the cause of the loop. I replaced it with: form method=POST action='%= response.encodeURL(j_security_check) %' ... and the logon was successful. This is because the browser will now POST the FORM
multiple tomcat instances for every application
Hi I have a question. which way is better for my scenario? I have one server - Centos 6 x64 , 8GB ram- and 3 java web application. 1- run multiple instances of tomcat 6 for each application and configure different port in server.xml for each one. 2- run just one instance of tomcat 6 for all three applications by configuring Catalina. personally I think solution 2 is far better. -- Best Regards, Ashkan R
Issue with missing files while migrating to Tomcat 7.0.32
Hi, We are currently upgrading our Tomcat from 5.5.23 to 7.0.32. The primary hurdle we are facing is with missing files(jsp), which Tomcat 5.5.23 used to tolerate. When it encounters a page that tries to include a file that is missing (Missing because the file needs to be loaded only conditionally - like for specific locales) it throws the following error: org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Servlet.service() for servlet jsp threw exception javax.servlet.ServletException: File quot;/application/MyInclude.jspquot; not found at org.apache.jasper.servlet.JspServlet.handleMissingResource(JspServlet.ja va:412) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:210) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatc her.java:749) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDisp atcher.java:605) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispat cher.java:544) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.ja va:954) We have many such files and updating all the relevant files to correct this seems to be practically impossible. Is there a way to turn off this STRICT validation in the Tomcat, so that it tolerates the missing files? Thanks and Regards, George Visit our Website at http://www.rmesi.co.in This message is confidential. You should not copy it or disclose its contents to anyone. You may use and apply the information for the intended purpose only. Internet communications are not secure; therefore, RMESI does not accept legal responsibility for the contents of this message. Any views or opinions presented are those of the author only and not of RMESI. If this email has come to you in error, please delete it, along with any attachments. Please note that RMESI may intercept incoming and outgoing email communications. Freedom of Information Act 2000 This email and any attachments may contain confidential information belonging to RMESI. Where the email and any attachments do contain information of a confidential nature, including without limitation information relating to trade secrets, special terms or prices these shall be deemed for the purpose of the Freedom of Information Act 2000 as information provided in confidence by RMESI and the disclosure of which would be prejudicial to RMESI's commercial interests. This email has been scanned for viruses by Trend ScanMail.
Re: multiple tomcat instances for every application
On 19.11.2012 14:18, Ashkan Rahmani wrote: which way is better for my scenario? I have one server - Centos 6 x64 , 8GB ram- and 3 java web application. 1- run multiple instances of tomcat 6 for each application and configure different port in server.xml for each one. 2- run just one instance of tomcat 6 for all three applications by configuring Catalina. It depends. It depends on memory usage pattern for your applications - you can tweak GC for each tomcat separately. It depends whether they leak and you need to restart tomcat - and do not want to disturb other ones. It depends on many other factors. Usually it's enough to go with option 2, but you have to decide yourself. -- Mikolaj Rydzewski m...@ceti.pl - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with tomcat and JRE1.7
On Nov 16, 2012, at 3:15 PM, Ralph Grove wrote: I stopped tomcat, deleted work and all of the application directories that were derived from war files. Same problem after restarting, though. It looks like all JSP's are failing. Couple more thoughts… 1.) Download a fresh copy of Tomcat 7.0.32, don't may any changes, don't deploy any of your apps. Start it up and see if the root and example applications work OK. 2.) On the Tomcat instance that generates the error, add the -verbose JVM option. This will log the classes that are loaded and the location from where they were loaded. Look to see if any of the Tomcat / JSP classes are being loaded from anywhere other than $CATALINA_HOME/lib or $CATALINA_BASE/lib. Dan Ralph On 11/16/12 3:01 PM, Daniel Mikusa wrote: On Nov 16, 2012, at 2:06 PM, Ralph Grove wrote: I just upgraded my JRE from 1.6 to 1.7, and the tomcat home page now throws an exception (below). The example apps, and my own apps are still working OK, though. Anyone else noticed this problem? Have not seen this before. Just a guess, but maybe try stopping Tomcat, clearing out the work directory and restarting Tomcat. Dan System configuration: MacOS 10.8.2 JRE 1.7.0_09 Tomcat 7.0.32 The server is at http://geo-query.cs.jmu.edu Thanks, Ralph Grove *type* Exception report *message* _java.lang.AbstractMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext;_ *description* _The server encountered an internal error that prevented it from fulfilling this request._ *exception* javax.servlet.ServletException: java.lang.AbstractMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext; org.apache.jasper.servlet.JspServlet.service(JspServlet.java:343) javax.servlet.http.HttpServlet.service(HttpServlet.java:722) *root cause* java.lang.AbstractMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext; org.apache.jasper.compiler.Validator$ValidateVisitor.init(Validator.java:514) org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1795) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:217) org.apache.jasper.compiler.Compiler.compile(Compiler.java:373) org.apache.jasper.compiler.Compiler.compile(Compiler.java:353) org.apache.jasper.compiler.Compiler.compile(Compiler.java:340) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:646) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) javax.servlet.http.HttpServlet.service(HttpServlet.java:722) *note* _The full stack trace of the root cause is available in the Apache Tomcat/7.0.32 logs. _ full trace: Nov 16, 2012 1:36:00 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [jsp] in context with path [] threw exception [java.lang.AbstractMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext;] with root cause java.lang.AbstractMethodError: javax.servlet.jsp.JspFactory.getJspApplicationContext(Ljavax/servlet/ServletContext;)Ljavax/servlet/jsp/JspApplicationContext; at org.apache.jasper.compiler.Validator$ValidateVisitor.init(Validator.java:514) at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1795) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:217) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:373) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:353) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:340) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:646) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
Re: My app stop respoding after 3 to 5 days in my Redhat server
On Nov 19, 2012, at 6:52 AM, Anuroop wrote: Hi, I am new for tomcat and linux. I have hosted my application on my redhat server, from last 1 week I am observing that its suddenly stops working after continuously running after 2 to 3days. Observation: Whenever my app stops responding I use to check port running or not using fuser 80/tcp command. I see that tomcat 80 port will be running fine. If I kill this port fuser 80/tcp -k and run tomcat once again my web app start working properly for again 2 to 3 days. I wanted to know whether is there any configuration issue in my tomcat, because of more request coming from the client machine it is stop working? Take some thread dumps when the application is no longer responding. This will tell you what is happening in the application once it has stopped responding to requests. Ideally you'd want three or more thread dumps, spread out with 15 - 20 seconds in between each thread dump. https://wiki.apache.org/tomcat/HowTo#How_do_I_obtain_a_thread_dump_of_my_running_webapp_.3F Dan Thanks and Regards, Anuroop - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: multiple tomcat instances for every application
On Mon, Nov 19, 2012 at 5:03 PM, Mikolaj Rydzewski m...@ceti.pl wrote: On 19.11.2012 14:18, Ashkan Rahmani wrote: which way is better for my scenario? I have one server - Centos 6 x64 , 8GB ram- and 3 java web application. 1- run multiple instances of tomcat 6 for each application and configure different port in server.xml for each one. 2- run just one instance of tomcat 6 for all three applications by configuring Catalina. It depends. It depends on memory usage pattern for your applications - you can tweak GC for each tomcat separately. It depends whether they leak and you need to restart tomcat - and do not want to disturb other ones. It depends on many other factors. Usually it's enough to go with option 2, but you have to decide yourself. -- Mikolaj Rydzewski m...@ceti.pl --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org yes, you are right. there are many good reasons. in fact these 3 apps are actually same, but they are for 3 completely separated customers. ( We develop it and then host it for users of customers) I googled before, it seams it's really usual run multiple tomcat. I think it's not good. why we run just one httpd for all hosts? I want to say, when I run 3 tomcats, some thing would run 3 times in memory. but when I run just one, there is one of them. 1 process will be responsible for all Catalinas. of course it's totally depends on tomcat architecture. -- Best Regards, Ashkan R
RE: My app stop respoding after 3 to 5 days in my Redhat server
From: Daniel Mikusa [mailto:dmik...@vmware.com] Subject: Re: My app stop respoding after 3 to 5 days in my Redhat server I wanted to know whether is there any configuration issue in my tomcat, because of more request coming from the client machine it is stop working? Take some thread dumps when the application is no longer responding. https://wiki.apache.org/tomcat/HowTo#How_do_I_obtain_a_thread_dump_of_my_running_webapp_.3F I would also recommend enabling GC logging or monitoring via JMX, since the symptoms are typical of heap exhaustion. For simplicity's sake, setting -verbose:gc is likely the easiest thing to do for those unfamiliar with Java. This link provides a reasonable description of how: http://freddyandersen.wordpress.com/2009/07/14/how-to-enable-verbose-gc-in-tomcat/ JMX monitoring via VisualVM or JConsole will also provide a lot of information in a more palatable format, but can be trickier to set up. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with tomcat and JRE1.7
The problem turned out to be one of the war files that I'm loading into Tomcat. JSP's work fine until that particular war file is deployed, but afterwards JSP's will no longer compile correctly. Only those JSP's that were previously compiled continue to work correctly. Without that war file loaded, Tomcat is working normally with JRE 1.7, so the JRE version wasn't the problem. Thanks, Ralph On 11/17/12 9:39 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralph, On 11/16/12 3:15 PM, Ralph Grove wrote: I stopped tomcat, deleted work and all of the application directories that were derived from war files. Same problem after restarting, though. It looks like all JSP's are failing. Do you precompile any of your JSPs? I would expect something like this to happen if you upgraded Tomcat itself, but the JRE shouldn't matter. What happens if you downgrade the JRE? - -chris ... -- Ralph F Grove, Ph.D. Professor James Madison University Department of Computer Science - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with tomcat and JRE1.7
Hi. Thanks for the update. Ralph Grove wrote: The problem turned out to be one of the war files that I'm loading into Tomcat. JSP's work fine until that particular war file is deployed, but afterwards JSP's will no longer compile correctly. So what does that mean ? compiling the JSP's in that .war somehow corrupts the compiler ? Sounds interesting. Only those JSP's that were previously compiled continue to work correctly. Without that war file loaded, Tomcat is working normally with JRE 1.7, so the JRE version wasn't the problem. Thanks, Ralph On 11/17/12 9:39 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralph, On 11/16/12 3:15 PM, Ralph Grove wrote: I stopped tomcat, deleted work and all of the application directories that were derived from war files. Same problem after restarting, though. It looks like all JSP's are failing. Do you precompile any of your JSPs? I would expect something like this to happen if you upgraded Tomcat itself, but the JRE shouldn't matter. What happens if you downgrade the JRE? - -chris ... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with tomcat and JRE1.7
It seems that the war file that I was installing contains its own version of the servlet API, which evidently conflicts with the one Tomcat 7 is using. I'm not sure of the details yet, but it you're curious you can find the war file within this zip: http://semwebcentral.org/frs/download.php/513/Parliament-v2.7.4-darwin.zip Thanks, Ralph On 11/19/12 12:32 PM, André Warnier wrote: Hi. Thanks for the update. Ralph Grove wrote: The problem turned out to be one of the war files that I'm loading into Tomcat. JSP's work fine until that particular war file is deployed, but afterwards JSP's will no longer compile correctly. So what does that mean ? compiling the JSP's in that .war somehow corrupts the compiler ? Sounds interesting. Only those JSP's that were previously compiled continue to work correctly. Without that war file loaded, Tomcat is working normally with JRE 1.7, so the JRE version wasn't the problem. Thanks, Ralph On 11/17/12 9:39 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralph, On 11/16/12 3:15 PM, Ralph Grove wrote: I stopped tomcat, deleted work and all of the application directories that were derived from war files. Same problem after restarting, though. It looks like all JSP's are failing. Do you precompile any of your JSPs? I would expect something like this to happen if you upgraded Tomcat itself, but the JRE shouldn't matter. What happens if you downgrade the JRE? - -chris ... .. -- Ralph F Grove, Ph.D. Professor James Madison University Department of Computer Science - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
CATALINA_BASE/conf/Catalina/localhost/APPNAME.xml is different from application's context.xml
I've been running a web application on Tomcat, when I make some changes in the application, including context.xml, and redeploy it, I start receiving an exception: javax.naming.NamingException: Cannot create resource instance at org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:143) at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304) at org.apache.naming.NamingContext.lookup(NamingContext.java:793) at org.apache.naming.NamingContext.lookup(NamingContext.java:140) at org.apache.naming.NamingContext.lookup(NamingContext.java:781) at org.apache.naming.NamingContext.lookup(NamingContext.java:140) at org.apache.naming.NamingContext.lookup(NamingContext.java:781) at org.apache.naming.NamingContext.lookup(NamingContext.java:140) at org.apache.naming.NamingContext.lookup(NamingContext.java:781) at org.apache.naming.NamingContext.lookup(NamingContext.java:153) at org.apache.naming.SelectorContext.lookup(SelectorContext.java:137) at javax.naming.InitialContext.lookup(InitialContext.java:392) After looking around, I realise that the appname.xml in CATALINA_BASE/conf/Catalina/localhost is different than an updated context.xml, so when an application tries to look up a jndi resource, it cannot find any. According to tomcat document, 2 files must be exactly the same. I come up with 2 explanations, and questions, for this case: - There is an issue that makes appname.xml unchanged during redeployment - Although I change context.xml, tomcat still stores an old version somewhere and use it instead of a new one I wonder if there is anyone see those issues before, if there is, I really appreciate any solutions. Or, if you have other explanation and/or question for my case, you're welcome! Thanks :) L PS: the tomcat is in my company's server, so I cannot just go and change appname.xml directly :( - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with tomcat and JRE1.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralph, On 11/19/12 11:30 AM, Ralph Grove wrote: The problem turned out to be one of the war files that I'm loading into Tomcat. JSP's work fine until that particular war file is deployed, but afterwards JSP's will no longer compile correctly. Only those JSP's that were previously compiled continue to work correctly. Without that war file loaded, Tomcat is working normally with JRE 1.7, so the JRE version wasn't the problem. Something similar was reported recently: a component packaged with a webapp was polluting one of Tomcat's ClassLoaders causing all sorts of devastation like this. See if you can find the thread in the archives (possibly in dev@) and add your own information to it: it may help shed some light on what is going on. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCqkaEACgkQ9CaO5/Lv0PAFwgCgmBu9BY/PJ76flm84DyFjKKUk UXgAn2nE0cCQmwDhT3It3rOJXZdByuAW =wPPj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CATALINA_BASE/conf/Catalina/localhost/APPNAME.xml is different from application's context.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Long, On 11/19/12 2:38 PM, Long Thai wrote: I've been running a web application on Tomcat, when I make some changes in the application, including context.xml, and redeploy it, I start receiving an exception: javax.naming.NamingException: Cannot create resource instance at org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:143) at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304) at org.apache.naming.NamingContext.lookup(NamingContext.java:793) at org.apache.naming.NamingContext.lookup(NamingContext.java:140) at org.apache.naming.NamingContext.lookup(NamingContext.java:781) at org.apache.naming.NamingContext.lookup(NamingContext.java:140) at org.apache.naming.NamingContext.lookup(NamingContext.java:781) at org.apache.naming.NamingContext.lookup(NamingContext.java:140) at org.apache.naming.NamingContext.lookup(NamingContext.java:781) at org.apache.naming.NamingContext.lookup(NamingContext.java:153) at org.apache.naming.SelectorContext.lookup(SelectorContext.java:137) at javax.naming.InitialContext.lookup(InitialContext.java:392) After looking around, I realise that the appname.xml in CATALINA_BASE/conf/Catalina/localhost is different than an updated context.xml, so when an application tries to look up a jndi resource, it cannot find any. According to tomcat document, 2 files must be exactly the same. I come up with 2 explanations, and questions, for this case: - There is an issue that makes appname.xml unchanged during redeployment - Although I change context.xml, tomcat still stores an old version somewhere and use it instead of a new one This is actually expected behavior: upon initial deployment, Tomcat will take the META-INF/context.xml file from your webapp and install it in conf/[Service]/[host]/[app].xml. After that, Tomcat will ignore any context.xml in your webapp unless you UNDEPLOY and REDEPLOY your webapp. This is a feature, not a bug: system administrators often need to customize context.xml for their environments and uploading a new WAR file should not clobber that configuration. If you need to update context.xml, you'll need to undeploy and redeploy (or edit the conf/.../[app].xml in place and bounce Tomcat). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCqkkYACgkQ9CaO5/Lv0PBZXwCfU7ImFOZy+uHPmijLdDoWBLgN RMYAniQU0B+3gvG08Ovwy7cKUyVaO16y =9+dE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: My app stop respoding after 3 to 5 days in my Redhat server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 11/19/12 9:13 AM, Caldarale, Charles R wrote: From: Daniel Mikusa [mailto:dmik...@vmware.com] Subject: Re: My app stop respoding after 3 to 5 days in my Redhat server I wanted to know whether is there any configuration issue in my tomcat, because of more request coming from the client machine it is stop working? Take some thread dumps when the application is no longer responding. https://wiki.apache.org/tomcat/HowTo#How_do_I_obtain_a_thread_dump_of_my_running_webapp_.3F I would also recommend enabling GC logging or monitoring via JMX, since the symptoms are typical of heap exhaustion. For simplicity's sake, setting -verbose:gc is likely the easiest thing to do for those unfamiliar with Java. This link provides a reasonable description of how: http://freddyandersen.wordpress.com/2009/07/14/how-to-enable-verbose-gc-in-tomcat/ JMX monitoring via VisualVM or JConsole will also provide a lot of information in a more palatable format, but can be trickier to set up. Also, anything suspicious in logs/* is a good place to start. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCqkp8ACgkQ9CaO5/Lv0PBHrwCfei7y6lk7ynpRtKYAaNkeCo2L /lcAoKDBwsKwCa9C0rkVDQJx36A+VFZd =AOnl -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: multiple tomcat instances for every application
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ashkan, On 11/19/12 9:10 AM, Ashkan Rahmani wrote: On Mon, Nov 19, 2012 at 5:03 PM, Mikolaj Rydzewski m...@ceti.pl wrote: On 19.11.2012 14:18, Ashkan Rahmani wrote: which way is better for my scenario? I have one server - Centos 6 x64 , 8GB ram- and 3 java web application. 1- run multiple instances of tomcat 6 for each application and configure different port in server.xml for each one. 2- run just one instance of tomcat 6 for all three applications by configuring Catalina. It depends. It depends on memory usage pattern for your applications - you can tweak GC for each tomcat separately. It depends whether they leak and you need to restart tomcat - and do not want to disturb other ones. It depends on many other factors. Usually it's enough to go with option 2, but you have to decide yourself. -- Mikolaj Rydzewski m...@ceti.pl --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org yes, you are right. there are many good reasons. in fact these 3 apps are actually same, but they are for 3 completely separated customers. ( We develop it and then host it for users of customers) Do your customers have any requirements like you must not host our data in the same process as other customers? You might find that you don't have a choice. I googled before, it seams it's really usual run multiple tomcat. Some environments run multi-Tomcat (we do in our environment), some run multi-tenant in a single Tomcat. As Mikolaj says, there are good reasons for choosing either strategy. We run webapps in separate Tomcat/JVM pairs for stability and serviceability: we can restart one web application (down to the JVM, of course) and not disturb any other webapps. We can upgrade, downgrade, etc. any part of one deployment and not affect other webapps. A memory leak or other resource exhaustion problem in one webapp doesn't affect any of the others. These are rare occurrences, but when they happen it's nice when they don't take-down the other webapps at the same time. I think it's not good. why we run just one httpd for all hosts? Why *do* you run only one httpd? Here's one reason: httpd is much more fault-tolerant than Tomcat (really the JVM), especially in prefork MPM mode: child processes that encounter problems simply die and are replaced. With Tomcat, an OOME caused by a single thread can take-down the whole JVM and all applications running on it. I want to say, when I run 3 tomcats, some thing would run 3 times in memory. Most JVMs use shared memory for some things like core classes, etc. Each process still gets a separate heap, etc. but running multiple JVMs on the same machine isn't as bad as it sounds. but when I run just one, there is one of them. 1 process will be responsible for all Catalinas. of course it's totally depends on tomcat architecture. Tomcat's architecture is not difficult to grasp. With 3 copies of the same application, this is less of an issue but one reason you might want to run different Tomcat instances is if you want to use a different JVM for each application. You may need a huge heap for one customer and so you want a 64-bit JVM while another customer only needs a 32-bit JVM. You could save some memory by having a smaller 64-bit-JVM-heap and a completely separate 32-bit-JVM-heap. You really have to evaluate your own requirements and make the decision that fits your situation best. If you think it's best to use a single JVM/Tomcat deployment, go right ahead and do it: nobody is going to tell you it's the wrong decision. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCqlTAACgkQ9CaO5/Lv0PBNKACcDwCV1bcw5LpUB48PGa+nVI24 HnwAni6cDmjt0H2P4Q2EBAu758BipjQe =Koik -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re:[OT] Servlet response blocking - problems with flush
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baron, On 11/18/12 9:00 PM, Baron Von Awsm wrote: I posted my issue at http://stackoverflow.com/questions/13446483/tomcat-servlet-response-blocking-problems-with-flush then discovered this mailing list. In the post cited above, I go into the details of the issues I'm having. An help appreciated. I see you identified and fixed your problem (needed Connection:close in the request) but I'm wondering why you didn't use HttpURLConnection instead of bare sockets in your client? HttpURLConnection does nice things like handling chunked encoding for you (for both the request *and* the response). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCqmKMACgkQ9CaO5/Lv0PAAzACgi0bYzFxcdAFT9kEgF0mrLdUE MBMAoJQ1yA6njZNHrp9CHBPYQV9VZBoK =J/qw -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue with missing files while migrating to Tomcat 7.0.32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 George, On 11/19/12 8:23 AM, George Chacko Manchimala wrote: We are currently upgrading our Tomcat from 5.5.23 to 7.0.32. The primary hurdle we are facing is with missing files(jsp), which Tomcat 5.5.23 used to tolerate. I would highly recommend that you inspect your old Tomcat 5.5 installation for tricks that you may have implemented there but not ported to your new Tomcat 7 environment. AFAIK, Tomcat has never been tolerant of missing files you are trying to include. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCqmRQACgkQ9CaO5/Lv0PBxOgCcDgWZK+d4l5mGxxyJ92wB7tij 98QAn2b0gsXcpOFuq+nfLX/bZt1NeaoT =QnW3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Delete catalina.out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josh, On 11/17/12 11:37 PM, Josh Gooding wrote: Moved this to the user list instead of the dev group. Hmmm strangely enough, I tried this on a CentOS system, I believe it forced me to be root over the tomcat user. It all depends upon the file permissions of catalina.out and the directory in which it resides. Deleting catalina.out certainly does not require root access in all cases, but I'm sure there are cases where root is required (e.g. because you are running Tomcat as root). I can re-check that shortly. I know it recreates the file catalina.out next time without any discourse, if I run the startup script as the tomcat user. :: update :: I figured out WHY it forced me to be root. Someone *(may or may not have been me) ran the /etc/init.d/tomcat start script as the root user, not as the tomcat user which I believe would cause this behavior. You should write your /etc/init.d scripts in such a way that they run under the proper user no matter who invokes them. For instance, if you want to run Tomcat as 'tomcat' then your init.d script should probably do sudo -u tomcat $CATALINA_BASE/bin/catalina.sh start or something to that effect. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCqmfEACgkQ9CaO5/Lv0PD8BgCgrexYyS13j84h9SJx4S2/eZl1 ZYUAn0N5SEsmWRJSuO8ezspEbYDl5+f0 =7zTN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: multiple tomcat instances for every application
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: multiple tomcat instances for every application Most JVMs use shared memory for some things like core classes, etc. Unfortunately, I don't think that's true, at least for the Sun/Oracle JVMs - only the client JVM uses shared classes, the server JVM does not. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: multiple tomcat instances for every application
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 11/19/12 3:58 PM, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: multiple tomcat instances for every application Most JVMs use shared memory for some things like core classes, etc. Unfortunately, I don't think that's true, at least for the Sun/Oracle JVMs - only the client JVM uses shared classes, the server JVM does not. Oh, I didn't realize that was a -client thing. Good to know. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCqp9UACgkQ9CaO5/Lv0PB70QCeIT8otERge/iDUs9XHAGdHa/5 beMAoJ7RcLZ3U7wsnVI3oC9AM7Y+O8gz =g6a7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CATALINA_BASE/conf/Catalina/localhost/APPNAME.xml is different from application's context.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/11/2012 20:10, Christopher Schultz wrote: If you need to update context.xml, you'll need to undeploy and redeploy (or edit the conf/.../[app].xml in place and bounce Tomcat). No need to bounce Tomcat (unless you have autoDeploy disabled). Tomcat will spot the change and reload the Context. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQqrKRAAoJEBDAHFovYFnnpQ8QAJmMfTKVU4s+dLdwMoeSGaV1 jfy2joNZBI0q+znVdF+WD5Glw7r7kmceGTL8nSBgBmcgT2LOJp5D6TDuA2kQ2xEq KDfgpMsqwas1pWKJV+BG7DRSTTeiysByCEAibtpltjHDdD56r1B7cj4v0cahOyYF pEE4KQRDczIayDDHqg9Pt6SnNPL5pmZASPOqYgZzG6PiFbABz2vAHjcrajhJV+f5 39TbNrvJDk0jhosTk4rMOuI5USfVpjB1yUl9OnGcI3tcopNGKhNbhr+OQ60yD1m2 U5g7781EBkNZyVH6aIw2Am7qskx/LBf8w+7E8NdpHboouMztec2aGbvjaVO7WVzs 9uuJ+0JJeJsgjRplx3maT1MkfKByxYM6Dy9mvaktbBTzb7UcmaSrABVQMJ6HtukX s1iA4b/xoX9G5nAxHeY9G+JYDa3C7CyAcnK3y+32NYANwoU7w4ghJ/JHq2ST3d7E lLbY80Et9UoIYJSoO2hcY4b+VQj2cnMlqN6SQnE5Gnz4+ueFoliY0LjFBxEB0dC0 ygym124vk4TmG62XjvJ/S0U/lw+VwRYABjUbi4IQNXdYWxJ+QNLXgSpDFGyaButY gTGUaKEZ/Slf53rpVZeFKuwsVqRyiH+6bw3BPvXiTW2gwuhj4hhvpEAzOzHojQKE hsCuEXTQlSILZ5DYzcJ1 =U+ZX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded
Hello! My team has been having an issue wherein our application occasionally fails to start up because Tomcat claims it can't find find a dynamically-created classfile. This doesn't happen all the time, and restarting Tomcat (albeit more than once, sometimes) resolves it. For example, I just started my Tomcat 6.0.26 instance (via Eclipse WTP, on OS 10.7.5), tried to load a page, and got: ** snip ** An error occurred at line: 1 in the jsp file: /WEB-INF/jsp/about/about_impact.jsp org.apache.jsp.tag.web.about_tag cannot be resolved to a type 1: %@ include file=../common/constants.jsp %templates:about ** snip/ ** The constants.jsp referenced above contains: %@ taglib prefix=templates tagdir=/WEB-INF/tags % ... and /WEB-INF/tags contains the about.tag file. The $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web directory exists, and it contains both about_tag.class and about_tag.java, with timestamps corresponding to when I loaded the page. I then deleted those files, and refreshed the page in my browser. about_tag.class and about_tag.java get recreated in that directory, but I still get the above error claiming about_tag can't be resolved. I then restarted Tomcat, refreshed the page in my browser, and all is well. I've also seen this happen regularly for my Windows-using colleagues, as well as in a non-Eclipse Linux-based 6.0.29 instance, and (hearsay) a colleague reported it happening in his Tomcat 7. Thinking it was a runtime race condition, we also tried telling Tomcat to load the JSP on startup via the web.xml, and while we did see the .java and .class files being created on startup, we still ran into the issue. We haven't yet tried pre-compiling our JSPs/TAGs before starting Tomcat -- but that shouldn't be necessary, right? I'd love some advice/insight in how I might investigate this further, or if there's a gotcha I might be running into. It feels like a race condition in the classloader, but I don't want to submit a bug report without a reliable test case, of course. Since we can't reliably recreate the situation, I'm having trouble putting that together. This seems to happen more often for me when I'm switching between substantially-different Git branches, so I thought it might have to do with the /work directory having older versions of the JSPs/TAGs, but one of my colleagues claims to clean her /work directory every time she switches branches, and before starting Tomcat, and still getting the issue. Thanks in advance for any help! Jim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Delete catalina.out
Chris, Yes I certainly agree with that. The init.d script should sudo -u tomcat the catalina.sh script. I believe that I have fixed all of them to correctly run as the tomcat user. - Josh On Mon, Nov 19, 2012 at 3:43 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josh, On 11/17/12 11:37 PM, Josh Gooding wrote: Moved this to the user list instead of the dev group. Hmmm strangely enough, I tried this on a CentOS system, I believe it forced me to be root over the tomcat user. It all depends upon the file permissions of catalina.out and the directory in which it resides. Deleting catalina.out certainly does not require root access in all cases, but I'm sure there are cases where root is required (e.g. because you are running Tomcat as root). I can re-check that shortly. I know it recreates the file catalina.out next time without any discourse, if I run the startup script as the tomcat user. :: update :: I figured out WHY it forced me to be root. Someone *(may or may not have been me) ran the /etc/init.d/tomcat start script as the root user, not as the tomcat user which I believe would cause this behavior. You should write your /etc/init.d scripts in such a way that they run under the proper user no matter who invokes them. For instance, if you want to run Tomcat as 'tomcat' then your init.d script should probably do sudo -u tomcat $CATALINA_BASE/bin/catalina.sh start or something to that effect. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCqmfEACgkQ9CaO5/Lv0PD8BgCgrexYyS13j84h9SJx4S2/eZl1 ZYUAn0N5SEsmWRJSuO8ezspEbYDl5+f0 =7zTN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
*shamless plug*
Shameless plug for Juergens Petclinic webapp i ported to Spring Framework 3.2.x http://www.laconiadatasystems.com/Downloads.html Comments, suggestions or advice are welcome Thanks, Martin Gainty __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
Re: multiple tomcat instances for every application
If you need a thumb rule, you usually choose multiple instances over single. Downside is, I think, it only uses little more memory. But else than that multiple instance is much better choice. I ran into exactly same issue. But I changed my application instead of running it multiple times. I separated databases for each users then routed them accordingly. Edited some logics but now every user has their own workspaces but single app. It is much easier now to develop maintain. This also could be an option. On Tue, Nov 20, 2012 at 5:42 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 11/19/12 3:58 PM, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: multiple tomcat instances for every application Most JVMs use shared memory for some things like core classes, etc. Unfortunately, I don't think that's true, at least for the Sun/Oracle JVMs - only the client JVM uses shared classes, the server JVM does not. Oh, I didn't realize that was a -client thing. Good to know. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCqp9UACgkQ9CaO5/Lv0PB70QCeIT8otERge/iDUs9XHAGdHa/5 beMAoJ7RcLZ3U7wsnVI3oC9AM7Y+O8gz =g6a7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
I have a question about websocket in tomcat7.0.30
Dears I am trying to build a chat-room in the internet by websocket based on tomcat7.0.30. the link between server and browser is not reliable. when I try to send a message to server from browser after the websocket connection having been built, the server has no respond, but this just occasionally occur. I would like to know why and I need your help. ** This e-mail is confidential for WistronITS corp. It may be legally privileged. If you are not the Addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return e-mail.Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. ***
Re: Form based login authentication
On Monday, November 19, 2012 12:33:26 PM Brian Burch wrote: This issue was discussed at length on the users mailing list under this topic: AuthenticatorBase setChangeSessionIdOnAuthentication without cookies http://mail-archives.apache.org/mod_mbox/tomcat-users/201209.mbox/%3C505EDA8 7.1080...@pingtoo.com%3E Authenticated access to restricted resources can only happen if the browser tells tomcat the session id when it requests ANY of those restricted resources. This is usually done via cookies, but when cookies are turned off the webapp has to keep reminding the browser of the session id - especially if the default behaviour is being used by the Container, when the session id is deliberately changed after authentication. Your protected jsp's MUST ALL use response.encodeURL() if you want your webapp to work properly without cookies. OK, my confusion came from accessing the root and expecting the web.xml welcome-file tag to take care of my base page. Is there a reason it doesn't get an encodeURL()? When I make my initial page something that exists *and* encode the j_security_check things work, at least I get to my next stopping point with a .jnlp (I'd like javaws to load securely *then* access the servlets securely. JWS documentation seems lacking and a couple of posts over here: http://forums.oracle.com/forums/forum.jspa?forumID=944start=0 haven't elicited any enlightening responses. When using an IDE you need to be careful of classloader issues. Tomcat's classloader environment is sophisticated and I sometimes encounter strange behaviour under netbeans because it tries to cache classes for speed, but this sometimes means my changes do not seem to have worked. This can always be proved by restarting netbeans. That's why I mentioned it. When I get confused at a response I stop the web server from inside Eclipse, when that fails to unconfuse me I exit Eclipse and start back up. So far I haven't seen much effect, i.e. my confusion remains, but at least I can break for coffee. I don't use eclipse, so I can't comment on your specific problems. However, you can simplify your debugging by running tomcat standalone and attaching your debugger to it. I may get to that point, probably when I'm testing the .war Thanks for looking at this. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded
On 19 Nov 2012, at 23:58, Jim open...@gmail.com wrote: Hello! My team has been having an issue wherein our application occasionally fails to start up because Tomcat claims it can't find find a dynamically-created classfile. This doesn't happen all the time, and restarting Tomcat (albeit more than once, sometimes) resolves it. For example, I just started my Tomcat 6.0.26 instance (via Eclipse WTP, on OS 10.7.5), tried to load a page, and got: ** snip ** An error occurred at line: 1 in the jsp file: /WEB-INF/jsp/about/about_impact.jsp org.apache.jsp.tag.web.about_tag cannot be resolved to a type 1: %@ include file=../common/constants.jsp %templates:about ** snip/ ** The constants.jsp referenced above contains: %@ taglib prefix=templates tagdir=/WEB-INF/tags % ... and /WEB-INF/tags contains the about.tag file. The $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web directory exists, and it contains both about_tag.class and about_tag.java, with timestamps corresponding to when I loaded the page. I then deleted those files, and refreshed the page in my browser. about_tag.class and about_tag.java get recreated in that directory, but I still get the above error claiming about_tag can't be resolved. I then restarted Tomcat, refreshed the page in my browser, and all is well. I've also seen this happen regularly for my Windows-using colleagues, as well as in a non-Eclipse Linux-based 6.0.29 instance, and (hearsay) a colleague reported it happening in his Tomcat 7. Thinking it was a runtime race condition, we also tried telling Tomcat to load the JSP on startup via the web.xml, and while we did see the .java and .class files being created on startup, we still ran into the issue. We haven't yet tried pre-compiling our JSPs/TAGs before starting Tomcat -- but that shouldn't be necessary, right? I'd love some advice/insight in how I might investigate this further, or if there's a gotcha I might be running into. It feels like a race condition in the classloader, but I don't want to submit a bug report without a reliable test case, of course. Since we can't reliably recreate the situation, I'm having trouble putting that together. This seems to happen more often for me when I'm switching between substantially-different Git branches, so I thought it might have to do with the /work directory having older versions of the JSPs/TAGs, but one of my colleagues claims to clean her /work directory every time she switches branches, and before starting Tomcat, and still getting the issue. What is the relationship between Git and Tomcat, exactly? Does Tomcat load an app (or its files) directly from a version controlled file system? p Thanks in advance for any help! Jim - 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
