|
»
»
20 Tips for Using Tomcat in Production
|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 | Next > |
 |
|
|
|
Re: 20 Tips for Using Tomcat in Production
by Christopher Schultz-2
::
Rate this Message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Chuck and Ole, Caldarale, Charles R wrote: >> From: Ole Ersoy [mailto:ole.ersoy@...] >> Subject: Re: 20 Tips for Using Tomcat in Production >> >> Anyone know if there is a way to verify that the >> jvm is running in server mode? > > Enable JMX and use JConsole to look inside, or install Lambda Probe and > look at its System Information tab. Get Lambda Probe from here: > http://www.lambdaprobe.org Or just look at the value for the system property "java.vm.name". It should either say "Client" or "Server" somewhere in there (at least when using a Sun VM). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1CKX9CaO5/Lv0PARAkV7AKDDs/bTF34kI4wvoZA8gCOYBM1XyQCghXgO e4NZ5zkjCv1wDdFfJ4fRCs0= =3sG/ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@... To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
RE: 20 Tips for Using Tomcat in Production
by Caldarale, Charles R
::
Rate this Message:
> From: Christopher Schultz [mailto:chris@...]
> Subject: Re: 20 Tips for Using Tomcat in Production > > Or just look at the value for the system property "java.vm.name". Yes, that's exactly what both JConsole and Lambda Probe do; I was just trying to suggest a mechanism that didn't require writing additional code. - 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 start a new topic, e-mail: users@... To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Tomcat Session Replication at undeploy/install (6.0.14 / windows)
by Filip Hanik - Dev Lists
::
Rate this Message:
hans.mader@... wrote:
> Hello, > > if I reload a context, all sessions are going to be > serialized and deserialized automatically. > > Is the same possible at undeploy / deploy? > yes, works the same way > The problem is, that all users are thrown out of their apps > if we "redeploy" under production. > wanna give us a test case? Filip > (I know thats not recommended, but sometimes its really necessary...) > > Thanks! > > Hans. > > > > > > Diese Nachricht ist ausschliesslich fuer den oben bezeichneten Adressaten bestimmt und enthaelt moeglicherweise vertrauliche Informationen. Sollten Sie nicht der oben bezeichnete Adressat sein oder diese Nachricht irrtuemlich erhalten haben, ersuchen wir Sie, diese Nachricht nicht weiterzugeben, zu kopieren oder im Vertrauen darauf zu handeln, sondern den Absender zu verstaendigen und diese Nachricht samt allfaelliger Anlagen sofort zu loeschen. Vielen Dank. > > This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee, you should not disseminate, copy, or take any action in reliance on it. If you have received this message in error, please immediately notify the sender of this message and delete this message and any attachment. Thank you. > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@... > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > > > --------------------------------------------------------------------- To start a new topic, e-mail: users@... To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: 20 Tips for Using Tomcat in Production
by Bugzilla from ole.ersoy@gmail.com
::
Rate this Message:
Chuck and Chris,
Thank you for the tips! I'll probably code a little servlet that has a peak, but now that I'm aware of Lambda Probe, I just have to play with it :-) Extremely cool toy! Thanks again, - Ole Caldarale, Charles R wrote: >> From: Christopher Schultz [mailto:chris@...] >> Subject: Re: 20 Tips for Using Tomcat in Production >> >> Or just look at the value for the system property "java.vm.name". > > Yes, that's exactly what both JConsole and Lambda Probe do; I was just > trying to suggest a mechanism that didn't require writing additional > code. > > - 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 start a new topic, e-mail: users@... > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To start a new topic, e-mail: users@... To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
|
|
|
RE: 20 Tips for Using Tomcat in Production
by br1
::
Rate this Message:
Maybe it should also be noted that the service installation batch file that
comes with the Tomcat's Windows binaries distribution (the zipped one) defaults to the server JVM, if available. The same should happen with the so called service installer version (the exe one) but I didn't check which jvm it defaults to.. though it is able to download the APR dll, so I don't see why it should make the service point to the client jvm instead. :-) Hope it helps -----Original Message----- From: Milanez, Marcus [mailto:Marcus.Milanez@...] Sent: 22 August 2007 13:59 To: Tomcat Users List Subject: RES: 20 Tips for Using Tomcat in Production If you are running tomcat under windows services, you can select which JVM you want to use through bin/tomcatXw.exe. -----Mensagem original----- De: Karel V Sedlacek [mailto:kvs1@...] Enviada em: quarta-feira, 22 de agosto de 2007 08:19 Para: Tomcat Users List Assunto: Re: 20 Tips for Using Tomcat in Production Thanks for this info,... How do I implement this tip? #18. Use the -server JVM option. This enables the server JVM, which JIT compiles bytecode much earlier, and with stronger optimizations. Startup and first calls will be slower due to JIT compilation taking more time, but subsequent ones will be faster. Karel > In putting #1 into the JAVA_OPTS (which it appears that is the > CATALINA_OPTS for our implementation), it doesn't appear to work, as > Tomcat doesn't restart. It could be our version -- which is currently > 5.0.30. please let me know if there are other steps we need to take > here as well. > > thanks, > Kim :-) > > On 8/21/07, Shane Witbeck <shane@...> wrote: >> >> I thought my latest blog post would be of interest to the people on >> this >> list: >> >> >> http://www.digitalsanctum.com/2007/08/18/20-tips-for-using-tomcat-in- >> production/ >> >> --------------------------------------------------------------------- >> To start a new topic, e-mail: users@... To unsubscribe, >> e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > --------------------------------------------------------------------- To start a new topic, e-mail: users@... To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... ---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)--- --------------------------------------------------------------------- To start a new topic, e-mail: users@... To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
RE: 20 Tips for Using Tomcat in Production
by br1
::
Rate this Message:
IMHO the only good reason to move a library out from an application and
place it into /common/lib (or /lib) is to get advantage of connection pooling. http://tomcat.apache.org/tomcat-5.5-doc/jndi-resources-howto.html Then, yes, if you have different database versions you might find yourself in the usual library versions nightmare.. :-) -----Original Message----- From: Diego Yasuhiko Kurisaki [mailto:diegoy@...] Sent: 22 August 2007 00:35 To: Tomcat Users List Subject: Re: 20 Tips for Using Tomcat in Production I agree, i'm not willing to pay the management overhead of putting my shared libraries to the tomcat common lib, unless my gains are very big in terms of memory consumption. I don't really think you should change for another one though, but you can make regards about the cons of that approach. Anyway, great work 5 stars. On 8/21/07, Ben Souther <ben@...> wrote: > > From: > Christopher Schultz > > I also agree with David and, uh, David, that #6 is a little dubious. > > Yes, moving shared libraries into the common/lib directory will save > > you some memory, but it creates a management headache when it comes > > to version numbers, WAR packaging, etc. Ideally, the WAR contains > > everything the webapp needs. If you rely on the servlet container to > > provide essential libraries, you are changing your deployment > > strategy significantly. > > +1 > > Starting with Servlet Spec 2.3 (I think) there has been an emphasis on > putting everything a web app needs to run into its war file. To put > include something that runs contrary to this 'best practice' in an > article of tips at this point in time doesn't sound like a good idea. > > I would seriously consider replacing that one with something else. > > > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@... > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > -- Diego Yasuhiko Kurisaki ---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)--- --------------------------------------------------------------------- To start a new topic, e-mail: users@... To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: 20 Tips for Using Tomcat in Production
by Bugzilla from ole.ersoy@gmail.com
::
Rate this Message:
Incidentally - since we are talking about pooling - should the executor configuration be a tip? It allows the connectors to share a single thread pool, rather than each connector having its own. This seems like a memory and performance slurpee to me.
Cheers, - Ole myrealbruno wrote: > IMHO the only good reason to move a library out from an application and > place it into /common/lib (or /lib) is to get advantage of connection > pooling. > http://tomcat.apache.org/tomcat-5.5-doc/jndi-resources-howto.html > > Then, yes, if you have different database versions you might find yourself > in the usual library versions nightmare.. :-) > > -----Original Message----- > From: Diego Yasuhiko Kurisaki [mailto:diegoy@...] > Sent: 22 August 2007 00:35 > To: Tomcat Users List > Subject: Re: 20 Tips for Using Tomcat in Production > > > I agree, i'm not willing to pay the management overhead of putting my shared > libraries to the tomcat common lib, unless my gains are very big in terms of > memory consumption. > > I don't really think you should change for another one though, but you can > make regards about the cons of that approach. > > Anyway, great work 5 stars. > > > On 8/21/07, Ben Souther <ben@...> wrote: >> From: >> Christopher Schultz >>> I also agree with David and, uh, David, that #6 is a little dubious. >>> Yes, moving shared libraries into the common/lib directory will save >>> you some memory, but it creates a management headache when it comes >>> to version numbers, WAR packaging, etc. Ideally, the WAR contains >>> everything the webapp needs. If you rely on the servlet container to >>> provide essential libraries, you are changing your deployment >>> strategy significantly. >> +1 >> >> Starting with Servlet Spec 2.3 (I think) there has been an emphasis on >> putting everything a web app needs to run into its war file. To put >> include something that runs contrary to this 'best practice' in an >> article of tips at this point in time doesn't sound like a good idea. >> >> I would seriously consider replacing that one with something else. >> >> >> >> >> --------------------------------------------------------------------- >> To start a new topic, e-mail: users@... >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > --------------------------------------------------------------------- To start a new topic, e-mail: users@... To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Java servlets
by Deepa Paranjpe-2
::
Rate this Message:
Hi all,
This is not a question specific to tomcat but more about servlets. I am using a dispatcher forward to invoke another servlet. Why do I get an exception --> java.lang.IllegalStateException: Cannot forward after response has been committed For some reason I am unable to find good documentation to do complicated servlets invocations. Does any one know? Ole Ersoy <ole.ersoy@...> wrote:Incidentally - since we are talking about pooling - should the executor configuration be a tip? It allows the connectors to share a single thread pool, rather than each connector having its own. This seems like a memory and performance slurpee to me. Cheers, - Ole myrealbruno wrote: > IMHO the only good reason to move a library out from an application and > place it into /common/lib (or /lib) is to get advantage of connection > pooling. > http://tomcat.apache.org/tomcat-5.5-doc/jndi-resources-howto.html > > Then, yes, if you have different database versions you might find yourself > in the usual library versions nightmare.. :-) > > -----Original Message----- > From: Diego Yasuhiko Kurisaki [mailto:diegoy@...] > Sent: 22 August 2007 00:35 > To: Tomcat Users List > Subject: Re: 20 Tips for Using Tomcat in Production > > > I agree, i'm not willing to pay the management overhead of putting my shared > libraries to the tomcat common lib, unless my gains are very big in terms of > memory consumption. > > I don't really think you should change for another one though, but you can > make regards about the cons of that approach. > > Anyway, great work 5 stars. > > > On 8/21/07, Ben Souther wrote: >> From: >> Christopher Schultz >>> I also agree with David and, uh, David, that #6 is a little dubious. >>> Yes, moving shared libraries into the common/lib directory will save >>> you some memory, but it creates a management headache when it comes >>> to version numbers, WAR packaging, etc. Ideally, the WAR contains >>> everything the webapp needs. If you rely on the servlet container to >>> provide essential libraries, you are changing your deployment >>> strategy significantly. >> +1 >> >> Starting with Servlet Spec 2.3 (I think) there has been an emphasis on >> putting everything a web app needs to run into its war file. To put >> include something that runs contrary to this 'best practice' in an >> article of tips at this point in time doesn't sound like a good idea. >> >> I would seriously consider replacing that one with something else. >> >> >> >> >> --------------------------------------------------------------------- >> To start a new topic, e-mail: users@... >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > --------------------------------------------------------------------- To start a new topic, e-mail: users@... To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... --------------------------------- Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. |
|
|
Re: Java servlets
by Glenn McCall
::
Rate this Message:
In a nutshell, once you forward you should ensure nothing else is sent to the output. Similarly once you start outputing a page, don't change your mind and forward.
Thus your code should look something like this: if (errorMessage != null) { response.sendRedirect (request.getContextPath() + "/someotherpage.jsp") ; return; } out.println ("<html>"); ... Not like this: if (errorMessage != null) { response.sendRedirect (request.getContextPath() + "/someotherpage.jsp") ; } out.println ("<html>"); ... This is a common mistake. I suspect that you are doing the reverse with the exception you are getting. That is you are doing this: out.println ("<html>"); ... if (somethingBadHasHappened) { errorMessage = "Uh Oh, something bad has happened."; } ... if (errorMessage != null) { response.sendRedirect (request.getContextPath() + "/someotherpage.jsp") ; } As for documentation, there are a great many titles on Servlets at the local book store. Also try searching the web there are plenty of tutorials and samples out there. I hope this helps Glenn Mc ----- Original Message ----- From: "Deepa Paranjpe" <deepa.paranjpe@...> To: "Tomcat Users List" <users@...> Sent: Thursday, August 30, 2007 10:01 AM Subject: Java servlets > Hi all, > > This is not a question specific to tomcat but more about servlets. > I am using a dispatcher forward to invoke another servlet. > Why do I get an exception --> java.lang.IllegalStateException: Cannot forward after response has been committed > > For some reason I am unable to find good documentation to do complicated servlets invocations. Does any one know? > > > > Ole Ersoy <ole.ersoy@...> wrote:Incidentally - since we are talking about pooling - should the executor configuration be a tip? It allows the connectors to share a single thread pool, rather than each connector having its own. This seems like a memory and performance slurpee to me. > > Cheers, > - Ole > |
|
|
Re: Java servlets
by David Smith-2
::
Rate this Message:
Well... has anything been written to the response before the forward?
If so, that'll do it. If what you really want is to include the output of various servlets and jsps in one response, you really need an aggrigator servlet that pulls together the output of various servlets. In jsp land, the c:import tag will do exactly this sort of thing. --David Deepa Paranjpe wrote: > Hi all, > > This is not a question specific to tomcat but more about servlets. > I am using a dispatcher forward to invoke another servlet. > Why do I get an exception --> java.lang.IllegalStateException: Cannot forward after response has been committed > > For some reason I am unable to find good documentation to do complicated servlets invocations. Does any one know? > > > > Ole Ersoy <ole.ersoy@...> wrote:Incidentally - since we are talking about pooling - should the executor configuration be a tip? It allows the connectors to share a single thread pool, rather than each connector having its own. This seems like a memory and performance slurpee to me. > > Cheers, > - Ole > > myrealbruno wrote: > >> IMHO the only good reason to move a library out from an application and >> place it into /common/lib (or /lib) is to get advantage of connection >> pooling. >> http://tomcat.apache.org/tomcat-5.5-doc/jndi-resources-howto.html >> >> Then, yes, if you have different database versions you might find yourself >> in the usual library versions nightmare.. :-) >> >> -----Original Message----- >> From: Diego Yasuhiko Kurisaki [mailto:diegoy@...] >> Sent: 22 August 2007 00:35 >> To: Tomcat Users List >> Subject: Re: 20 Tips for Using Tomcat in Production >> >> >> I agree, i'm not willing to pay the management overhead of putting my shared >> libraries to the tomcat common lib, unless my gains are very big in terms of >> memory consumption. >> >> I don't really think you should change for another one though, but you can >> make regards about the cons of that approach. >> >> Anyway, great work 5 stars. >> >> >> On 8/21/07, Ben Souther wrote: >> >>> From: >>> Christopher Schultz >>> >>>> I also agree with David and, uh, David, that #6 is a little dubious. >>>> Yes, moving shared libraries into the common/lib directory will save >>>> you some memory, but it creates a management headache when it comes >>>> to version numbers, WAR packaging, etc. Ideally, the WAR contains >>>> everything the webapp needs. If you rely on the servlet container to >>>> provide essential libraries, you are changing your deployment >>>> strategy significantly. >>>> >>> +1 >>> >>> Starting with Servlet Spec 2.3 (I think) there has been an emphasis on >>> putting everything a web app needs to run into its war file. To put >>> include something that runs contrary to this 'best practice' in an >>> article of tips at this point in time doesn't sound like a good idea. >>> >>> I would seriously consider replacing that one with something else. >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To start a new topic, e-mail: users@... >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@... > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > > > > --------------------------------- > Boardwalk for $500? In 2007? Ha! > Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. > --------------------------------------------------------------------- To start a new topic, e-mail: users@... To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
|
| < Prev | 1 - 2 - 3 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
