Thanks to Craig and Chris for your suggestion. Another strange problem that happened to me with JavaWebserver2.0 I have a servlet called "Login", which I added to the server engine using (ADMIN applet-->WEB SERVER-->MANAGE-->SERVLETS-->ADD). SCENARIO-1 =========== 1) I tried to access this "Login" servlet. After that I made some changes to the servlet, re-complied, and re-copied to \javawebserver2.0\servlets directory. 2) When I try to access the "Login" servlet second-time, I don't see the changes. 3) What would have gone wrong? SCENARIO-2 =========== 4) I unloaded and re-loaded this servlet on the java server engine using the JavaWebserver2.0 Admin Applet (http://hostname:9090). 5) But still I cannot see the changes. 6) What would have gone wrong? 7) when I checked "Log Monitor", I found two instances of the same servlet on the servlet engine. 8) Any better way to do without shutting down the webserver. Thanks in Advance Louis >From: "Craig R. McClanahan" <[EMAIL PROTECTED]> >Reply-To: "A mailing list for discussion about Sun Microsystem's Java > Servlet API Technology." <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: servlet caching, Single Thread Model >Date: Tue, 9 Nov 1999 21:53:13 -0800 > >Chris Pratt wrote: > > > > > > Is there any limit on how many instances that the server can create? > > Hope > > > you can answer to my question. Thanks in advance. > > > > While there is no limit required by the specification, most servlet >engines > > will impose some limit. Most are programmable. > > > >To slightly nit-pick, there is a limit on the number of instances in the >2.2 >spec -- if a servlet does not implement SingleThreadModel (STM), there will >be >at most one instance per JVM (there is more than one JVM only in a >distributed >servlet container where you have flagged your web-app with the >"distributable" >tag). If a servlet does implement STM, it is up to the servlet container >to >decide (usually based on configuration parameters) what the maximum number >of >instances is. > >Note that there is no requirement to support a pool of instances of an STM >servlet to improve performance -- there may be only one, which has the same >negative performance impact as synchronizing the doGet() and doPost() >method. > >In nearly all cases, STM is a *very* poor choice because it misleads you >into >believing that you've taken care of all of your multithread concerns. You >are >*far* better off learning how to program safely in a multithreaded server >environment in the first place. > >Craig McClanahan > >___________________________________________________________________________ >To unsubscribe, send email to [EMAIL PROTECTED] and include in the body >of the message "signoff SERVLET-INTEREST". > >Archives: http://archives.java.sun.com/archives/servlet-interest.html >Resources: http://java.sun.com/products/servlet/external-resources.html >LISTSERV Help: http://www.lsoft.com/manuals/user/user.html ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
