Re: disabling session management
Hi, you could also use a SessionListener an invalidate sessions immediately after being created or you could write your own implementation of |org.apache.catalina.Manager |http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html and configure it to be used instead of the default manager. Can't be too difficult if jit ust has to serve as a NOP implementation... However I would prefer to figure out why sessions are unexpectedly created at all. Cheers, Michael Christopher Schultz wrote: Emerson, On 10/8/2010 10:25 AM, emerson wrote: We been doing some tuning on our TC environment and noticed that tomcat is holding 30 megabytes of classes related to session management. Which classes, specifically? This is on our middletier servler, where sessions are irrelevant. Okay, great. Is there a way to disabled session management for this server? Don't call request.getSession(). If you have JSPs (in a middle tier?), make sure they all have session=false in their @page directives. What is the impact of using session-timeout = 0? Your sessions will never time out, and your problem will likely get worse. We currently use 30 minutes for the session-timeout. You could always set it to 1 minute just to be sure they don't last very long if they are accidentally created. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- TNG Technology Consulting GmbH, Betastr. 13a, D-85774 Unterföhring Geschäftsführer: Henrik Klagges, Gerhard Müller, Christoph Stock Amtsgericht München, HRB 135082 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Running schduled jobs
Ravi Sharma wrote: Hi All, I need to run some threads at particular time during the day, does Tomcat provide any such facility? If not then whats the other best way to go for it. Well for scheduled jobs Quartz is a common tool, if java.util.Timer is not sufficient. Certainly not Tomcat-related however as only full JEE containers have buildt-in timer support. Basically i recalculate my site's visitor data every 30 minute and keep in cahce and then display to users, 30 minute delay for my data is fine but atleast i dont need to run queries to find those data for each request. Now every 30 minute i want to run those query and update the cache. How can i achive it.? Trying to use java.util.Timer or Quartz for this particular problem appears architecturally questionable however. Preferably you would have an O/R mapper like Hibernate an rely on some second level cache like EHCache to do thus common DB query caching stuff via configuration instead of implementing such common tasks on your own. Maybe you want to rethink that from an architectural point of view to get things right for all DB queries, unless the problem described is very focused on that particular caching problem. Sometimes OSCache's JSP-based caching can also be a valid solution, if all you want to do is to cache some view results: http://www.opensymphony.com/oscache/wiki/JSP%20Tags.html Thanks, Ravi. Cheers, Michael -- TNG Technology Consulting GmbH, Betastr. 13a, D-85774 Unterföhring Geschäftsführer: Henrik Klagges, Eike Reinel, Christoph Stock Amtsgericht München, HRB 135082 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
mod_jk: Expected behaviour for ajp-pool currentThreadCount
Hello, I'm currently analysing issues with a quite old Tomcat 5.5.17, mod_jk 1.2.15 and Apache 2.0.55 loadbalanced setup with 4 Apaches (worker.c) and 4 Tomcats. Questions are: * Can anyone explain why Apache SYN requests to Tomcat don't get answered (probably this happens only if maxClients exceeds Tomcat AJP pool sizes). * Shouldn't the AJP thread pool shrink to maxSpareThreads, if idle, or will threads stay open if Apache ever requested them? Currently there are 4 Apaches, 2 with StartServers 2 MaxClients 300 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 and 2 more with StartServers 2 MaxClients 200 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 that have problems with hung SYN requests when getting near the 4 Tomcat's default AJP thread pool size of 200. Current guess was that it's simply a bad idea to have 2*300+2*200=1000 maxClients on Apache side and just 4*200=800 AJP threads (if evenly balanced) on Tomcat side. So firstly increased Tomcat threads to maxThreads=500 to find some peak. All other AJP connector settings are default, resp. not defined. Meanwhile we log the JMX currentThreadCount for the AJP-Pools and the thread count only increases. However even after peak hours the currentThreadCount does not decrease. However would expect to get back to the maxSpareThreads default of 50 during night time. Can anyone explain why the AJP thread count stays high? I saw that one could configure mod_jk connection_pool_timeout which is not done yet. Could that be the reason for the thread pool never reducing the thread count even though the AJP thread pool has a maxSpareThread setting (i.e. doesn't this have an effect without pool timeout?)? What could be the reason for SYN requests of the Apache that never get answered by Tomcat? Thanks, Michael Echerer -- TNG Technology Consulting GmbH, Betastr. 13a, D-85774 Unterföhring Geschäftsführer: Henrik Klagges, Gerhard Müller, Christoph Stock Amtsgericht München, HRB 135082 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance monitoring for web applications
Shimol Shah wrote: Hi, Hi, I am trying to look for a way to programmtically find CPU resources used and memory used for indivudual web applications. I have given it many tries on Google but only thing I could find was some third party tool vendors that give solutions to performance monitoring. Instead what I am looking for is the programmatic way of knowing CPU and memory usage by a particular web application. I would really appreciate if someone can point me to a right direction. I can work it out form there. Thanks, Shimol. Try the Java 5.0+ javax.management API: http://java.sun.com/j2se/1.5.0/docs/api/index.html?javax/management/package-summary.html http://download.java.net/jdk6/docs/jre/api/management/extension/com/sun/management/package-tree.html http://download.java.net/jdk6/docs/jre/api/management/extension/com/sun/management/OperatingSystemMXBean.html#getProcessCpuTime() with Java 6.0 there might be more options: http://download.java.net/jdk6/docs/api/java/lang/management/OperatingSystemMXBean.html#getSystemLoadAverage() and have a look at www.lamdaprobe.org and its sources to get an idea. Basically you can get the CPU time the process uses and can put it into relation to a period of time to get the relative CPU usage like lamdaprobe does it. However it'll be only the usage of the JVM process not all processes. No clue how to measure per thread and you'll have to find a way to map all http connector threads in use at each point in time to each webapps to get a sum of cpu times for a certain webapp and put it into relation to the overall process time. Maybe you could weave something before and after each connector thread with aspectJ to measure to time the thread was used or have your own implementation. Nevertheless this wouldn't measure the cpu time of that thread, too. For memory it'll be difficult, too. Probably you can measure all objects similar to what lamdaprobe does for the Httpsession object. Instead you'd have to measure all objects for one classloader. As you have one classloader per webapp, this could be what you want. I guess it'll be quite Tomcat and SunVM specific, if it works at all. Cheers and good luck. Let us know if you found a way. Michael - 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: Tomcat 5.5 Load Balancing Rule Classes
Madhur K Tanwani wrote: I am trying to build a load balancer which enforces the following :- - chooses from the available alive workers from the cluster, in a Round-Robin / Least-Load-First manner - implements session affinity See: http://tomcat.apache.org/connectors-doc/ - includes fail over support with session replication, so there is no loss of session data - The transition is transparent to the user. Hence, whatever be the redirectURL, the URL in the browser should not change See: http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html On another note, I wanted to ask the clustering and load-balancing gurus, whether I've taken up the correct approach. I see that many load balancing tutorials focus on Apache as the load balancer with Tomcat as the worker in clusters. But since most of them are old, I assume the new Tomcat 5.5 features did not make it then - hence the question. You can use Apache2, mod_jk1.2 and Tomcat's session replication for what you plan to do. However session replication looks as easy as putting distributable/ into web.xml, but actually keeping the webapp session serializable and small has to be kept in mind always. Cheers, Michael - 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: Tomcat as a standalone webserver. Why not?
Peter Lin wrote: I'm gonna say that's quite a bit of myth here. If SSL is important, get a cheap SSL enabled router. Doing software SSL is waste of CPU power and impacts the server's stability. Anyone that has a lot of HTTPS traffic shouldn't be using software SSL in my bias opinion. If you are so desparate that you need software SSL, as remy says, there's APR. no need to stick apache httpd infront. Guess my information regarding Tomcat + SSL was a bit outdated. Last time AFAIR I measured Tomcat 5.0.x (no APR avail) vs. Apache+Tomcat 5.0.x. So good to know there are new options with 5.5.x, Remy. Well regarding the HW vs. SW question, there's another point: Often you have different DMZs (e.g. you are required to do it for security reasons and some forced protocol changes) eventhough you know that you'll have servers running idle. In that case you might have pure Apache HTTPD servers in one DMZ and some Tomcats in another DMZ. Some HTTPS handling and not just AJP forwarding will use at least some CPU time in your external machines. ;-) if an SSL-enabled router is not what other people want. Cheers, Michael my bias 2 bits on this topic peter On 6/1/06, Remy Maucherat [EMAIL PROTECTED] wrote: On 6/1/06, Michael Echerer [EMAIL PROTECTED] wrote: Danny Lee wrote: Hi guys! I wondering if it's really so good to use Tomcat behind a real web server like Apache or IIS. In case you have a lot of HTTPS traffic, you'll find that having Apache handle SSL is faster than the Java implementation that Tomcat can offer. IMHO for HTTP traffic performance is almost comparable as long as you don't need 100% perf, but for HTTPS Apache is definitely better already with not so many concurrent requests. Great post. And now, for the real information: http://tomcat.apache.org/tomcat-5.5-doc/apr.html :) -- x Rémy Maucherat Developer Consultant JBoss Inc x - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: servlet api problem
Remove the servlet-api.jar from your web apps. This jar is provided by Tomcat already. You might need it to build your app, but don't deploy it. Cheers, Michael Asaf Lahav wrote: *When starting tomcat, I get the following log:*** 28/05/2006 21:03:39 org.apache.catalina.loader.WebappClassLoader validateJarFile INFO: validateJarFile(C:\Tomcat\webapps\muse\WEB-INF\lib\servlet-api.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class 28/05/2006 21:03:39 org.apache.catalina.loader.WebappClassLoader validateJarFile INFO: validateJarFile(C:\Tomcat\webapps\muse\WEB-INF\lib\servlet.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class *Another log which indicates a problem:* 28/05/2006 21:03:39 org.apache.catalina.loader.WebappClassLoader validateJarFile INFO: validateJarFile(C:\Tomcat\webapps\muse\WEB-INF\lib\servlet-api.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class 28/05/2006 21:03:39 org.apache.catalina.loader.WebappClassLoader validateJarFile INFO: validateJarFile(C:\Tomcat\webapps\muse\WEB-INF\lib\servlet.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class 28/05/2006 21:03:43 org.apache.catalina.core.StandardContext start What could be the reason? What do these log entries mean? Thanks advance, **Asaf Lahav** **VP RD, Prima Grid LTD.** Cellular: 972-54-4717955 Phone: 972-3-6540255 Fax: 972-3-6540254 - 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: Advice me
[EMAIL PROTECTED] wrote: Hello all, How can i make the Tomcat opens to my servlet once i call it, using this call http://localhost:8080; ??? Basically this works, if you put a webapp context called ROOT into the webapps directory. You should have a look at the Tomcat default installation. webapps/ROOT contains the welcomedocu pages. This should give you a clue how to configure your own servlets/JSPs. What i wan to say that i want me own servlet be the default page, and I am You'll need a servlet mapping in your web.xml to do this. using apache-tomcat-5.5.17 Might help, too: http://wiki.apache.org/tomcat/HowTo#head-e82228c43a0ce77f71ebe64fc99ced33c9506ffe Cheers, Michael Thanks - 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: problem in GC tuning
Prashant kumar wrote: Hi All, 1) Is there any means by which GC takes less CPU, I mean that it can take longer time to complete its one cycle (as memory is not a constraint) ? You've set quite a lot of heap 3400m. Do you really need that much memory? The more you set, the more the GC needs to scan. If it's unused however, try reducing Xmx and Xms to values that are sufficient for your app. Then try to size the generations to get smaller chunks to be scanned and check the survivor ratios. Give the incremental GC a try. Might get worse, but probably it works. http://java.sun.com/docs/hotspot/gc1.4.2 2) Do writing of logs at higher loads have some impact on the performance? You should definitely disable GC logging in production, if you don't need it for diagnosis anylonger. Cheers, Michael - 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: how to persist a session
Vikas Jain wrote: Hi, I am using java server faces. My web server is Tomcat5.0. I want to persist my session that is the session should continue until user logs out. I don't want to do this task through session-config session-timeout0/session-timeout /session-config in web.xml. Any help will be highly appreciated... A cookie based approach might not be feasible for a lot of data and Ajax/Javascript tricks to persist a sesssion by reloading something (e.g. a .gif) require Javascript, of course. However JSF or Tapestry 4.0 support persistance of client-side session state by configuration means. See: http://www.theserverside.com/news/thread.tss?thread_id=33991 http://howardlewisship.com/blog/2005/04/property-persistence-on-client.html For Tapestry just use: property name=myProperty persist=client/ In case you neither want to use JSF or T4 you might still create your own session state serialization/deserialization code/jsp tags to do it. However be aware that you must not trust client data and that you might pass huge hidden fields along with each request. Crypting data is recommended. Using client-side state you won't even need a log out anylonger, except in order to reset/clean state. Cheers, Michael With Thanks And Regards Vikas Jain - 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: META-INF/context.xml and custom Manager
John D'Emic wrote: Hey all, Hi, I have a custom Manager class I'm trying to use for a single webapp. It seems the way to do this is to have a context.xml file in the exploded webapp's META-INF directory. I have the following: Well, META-INF/context.xml is the right place, but for a .war file that you deploy. Tomcat will extract this xml and copy it to \conf\Catalina\localhost\your-context-name.xml Not sure if it works for deployment of true exploded .wars. So please check that this file actually contains your META-INF/context.xml content and not just a plain empty context element because you once deployed your webapp beforehand. To my experience, if META-INF/context.xml changes seem to have no effect, it is usually because the \conf\Catalina\localhost\ deployment descriptor is still unchanged. Unfortunately I'm not sure how Tomcat decides when to update that file and when not (not even sure if something is bogus there), and if it makes a difference whether you have an exploded dir vs. .war file, how timestamps influence it, etc. If that didn't help, try to config the context directly in your server.xml just to be sure. Cheers Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet inter-communication
Samuli Elomaa wrote: Hi, Is there any otherway for two servlets in same tomcat to communicate together except by http requests? Eg. could two servlets use somekind of shared memory? or send signals to each other? Hi, whatever others suggested, just use the Servlet Spec 2.3+ standard: The webapp context scoped shared memory is here: http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/ServletContext.html#setAttribute(java.lang.String,%20java.lang.Object) http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/ServletContext.html#getAttribute(java.lang.String) The event listener is here: http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/ServletContextAttributeListener.html Singletons are evil, even more devilish for webapps. ;-) Cheers, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat: The Definitive Guide Question
Marc Farrow wrote: Tomcat 4 and Tomcat 5 changed a bit in the way they handle and load contexts. I wouldn't suggest getting a Tomcat 4 book for a Tomcat 5 server. SAMS has a Tomcat 5 Unleashed which is pretty good, but I don't think it covers Tomcat 5.5. I read Professional Tomcat 5 (Wrox Press). Not bad, but I'd say for real problems the mailing list is still the best source of information. BTW the Tomcat online documentation is in fact far above open source average and some books are mainly a beautified copy of it. Professional Tomcat 5 also doesn't cover 5.5.x, just 5.0.x and I'm not aware of any 5.5.x book. I read the first Tomcat book after using several Tomcat 4.1 and 5.0 versions productive and was slightly disappointed that the above book didn't really contain secrets you could know after studying the online documentation. Probably just stick to the online help and this list. Cheers, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple instances of Tomcat on same machine
keith wrote: Hi all, I'm wondering if anyone knows what are the advantages of running the same web application in multiple instances of Tomcat on the same machine (with a dual duo-core Intel processor). Do having multiple instances affect performance positively or negatively taking in to account that the machine has multiple processors? I doubt there's a performance gain as you could also increase the default settings of just one Tomcat. Of course, each JVM adds memory overhead. Depending on how many webapps you deploy this might not be the issue compared to your webappss' memory consumption however. Pro: 1) However in case you have more memory in your machine than a JVM can possible use with Windows/Linux you might want to start multiple Tomcats/JVMs and distribute webapps or even the same webapp to distribute the memory consumption of one app's sessions and loadbalance. 2) You might want two Tomcat instances with loadbalancing in front in order to do maintainance work. Of course, you could just have one hot-standby instead of using both. So probably only a good idea if combined with #2. 3) If you don't trust your VM you might hope if one crashes you still got one ;-) However OOMs might be difficult to detect properly by a loadbalancer and that Tomcat might still hang around, but not stable. 4) you prefer to distribute webapps, need a complex vhost setup, add what you like, but dislike configuring just one Tomcat. Instead you want one Tomcat per special setup. Cons: 1) keeping config in sync 2) webapps installed multiple times (or symlinked /webapp with other effects...). Tomcat updates shouldn't be more effort as long as you stick just to patch versions as you'll still only have on binary installation CATALINA_HOME vs. multiple CATALINA_BASE configs. 3) more complex, might want session clustering to get session replications Cheers, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classloading questions
Christopher Piggott wrote: As an experiment, I placed a file in the webapp dir of a servlet (not in WEB-INF but in the directory above it) and attempted to read it using getResource(). What I found was that I could not locate the resource unless I used getServletContext().getResource(). Your basic assumption that getServletContext().getResource() works by using classloader means is simply wrong. If you look at the JavaDoc of ServletContext it says that getResource() works file based (relative to the context root) and does not use the classloader. http://tomcat.apache.org/tomcat-5.0-doc/servletapi/javax/servlet/ServletContext.html#getResource(java.lang.String) Cheers, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Class loading from within a servlet: interface definition not found
David Smith wrote: most likely the shared classloader instead. If possible, move the handler.jar from shared/lib to WEB-INF/lib of your webapp and the problem should go away. It took me a few minutes to realize that this was not a ClassNotFound exception, but something else. Reading docs I figured out that the most probably cause is that the servlet's classloader was able to find the handler class, but then it failed to load one of the things it depended on, specifically it was able to find handlerClass but not the interface class that it depends on. Trouble is: the interface .class file is right there in WEB-INF/classes/com/something/DatabaseRequestHandler.class just like it should be. So, I am stumped why the class loader would be able to find the handler class in $CATALINA_BASE/shared/lib but NOT the interface that it implements which is in WEB-INF/classes. What you are trying to do won't work or at least is asking for much classloading trouble. Its basically the same as if you try to put a jdbc jar in common/lib AND in WEB-INF/lib or put the servlet api which is included by Tomcat into WEB-INF/lib again. Bad idea and sometimes caused by unwanted glitches in ant build.xmls as it is convenient to put all .jars into the .war that were required for the build, eventhough the are harmful when deployed. Even if the classloader would find your classes and interfaces if you rebundle your jars you'll run into problems (class cast exceptions) as soon if you try to cast objects loaded by two different classloaders later on. E.g. you have created a Handler class by the shared classloader and later on cast in your webapp by using the webapp classloader to use it. Remember: for instanceof to be true it's not enough to have the same class, two objects have to be loaded by the same classloader, too. Repackage your code, use the same classloader, or as David said put everything into WEB-INF/lib. Cheers, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5 Deply Multi-Servlet
[EMAIL PROTECTED] wrote: Hi, Hi, i upgrade recently my tomcat from 4.1 to 5.5. I have some problem on deploy. My application is made of about 200 servlet. In the old tomcat version i specify a context element in server.xml and all works in the right way. In the new version this configuration doesn't works. I try to modify the web.xml in folder WEB-INF. The question is: in file web.xml i have to specify all the 200 servlet by element servlet and servlet-mapping or is there a smarter way to do that? I guess you relied upon the so called invoker servlet. In later 4.1.x versions it is commented out in the default conf/web.xml as it shouldn't be used for production sites. Same is true for 5.0.x and 5.5.x versions. However you might enable it again as you have an uncommon amount of servlets compared to others using front-controller servlet style web frameworks with just a single servlet. sTe Cheers, Michael P.S. from conf/web.xml - just enable it !-- servlet servlet-nameinvoker/servlet-name servlet-class org.apache.catalina.servlets.InvokerServlet /servlet-class init-param param-namedebug/param-name param-value0/param-value /init-param load-on-startup2/load-on-startup /servlet -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
George Sexton wrote: -Original Message- From: Duan, Nick [mailto:[EMAIL PROTECTED] HttpSession should be implemented (it's just an interface). In fact, the session attributes were implemented as a Hashtable in tomcat, not a Hashmap (just double checked the latest 5.5.15 src of tomcat). As we all know, Hashtable already has thread sync built in. So that's why additional synchronization on HttpSession in tomcat is unnecessary. SVN: StandardSession.java in Tomcat 5.0.x and 4.1.x use HashMap, 5.5.x HashTable. I believe this is a fairly recent change. There was a major thread about this in November. In short, it was a HashMap and it got changed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
GB Developer wrote: Sessions are (never?) thread-safe. Which is perhaps one reason why SingleThreadModel was deprecated. People thought by using that interface that they would never have to worry about synch issues again. The servlet spec 2.5 draft says in SRV 2.2.1. (should be similar in 2.4.). Even spec 2.3 had this warning note eventhough in 2.3. SingleThreadModel wasn't deprecated: Objects that are accessible to more than one servlet instance at a time, such as instances of HttpSession, may be available at any particular time to multiple servlets, including those that implement SingleThreadModel. So this was one of the reasons to deprecate this. Chuck and you are right. I described ways to achieve concurrent access to one session using multiple servlets (or multithreaded access). Just think of frames or the infamous IE double submit problem for more examples. Cheers, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
Dakota Jack wrote: Actually, any class with only local variables is always thread safe. True for locals, but we were talking about instanceclass variables, actually. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
Michael Echerer wrote: Dakota Jack wrote: Actually, any class with only local variables is always thread safe. True for locals, but we were talking about instanceclass variables, actually. You may of course still have instanceclass variables... ThreadLocals (usually static) work fine ;-) http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ThreadLocal.html Cheers, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
Christian Stalp wrote: Hello out there, I want to build a servelt which access a database. To avoid race-conditions and to realize synchronous access, I decited to make a Singe Thread Servlet. But Eclipse told me that this is no longer a usable code. Usually the best solution is to synchronize just the part that accesses the single resource (the DB) instead of using single thread. In worst case you won't even achieve what you want using single thread mode because according to the servlet specification servlet containers are free to pool servlets, if it implements SingleThreadModel. Hence you could have multiple pooled instances that be no means guarantee an synchronized access to your database in case of simultaneous requests hitting different instances. So SingleThreadModel is deprecated for good reason, since servlet spec 2.4 and also for 2.5. You are better of synchronizing yourself. Don't rely on SingleThreadModel as an easy way to get around multithreading issues. In case you have different code parts accessing your DB or various clients, it might not even help to just sync one servlet. You might even have to set database transaction isolation level to fit your needs for your DB connections. Most DBs have read-committed by default, but it might be that you need isolation level up to synchronized. Depends on your use case... Cheers Michael So what can I do else? Thank you... Gruss Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
Remy Maucherat wrote: On 1/6/06, Michael Echerer [EMAIL PROTECTED] wrote: In worst case you won't even achieve what you want using single thread mode because according to the servlet specification servlet containers are free to pool servlets, if it implements SingleThreadModel. Hence you could have multiple pooled instances that be no means guarantee an synchronized access to your database in case of simultaneous requests hitting different instances. So SingleThreadModel is deprecated for good reason, since servlet spec 2.4 and also for 2.5. You are better of synchronizing yourself. Don't rely on SingleThreadModel as an easy way to get around multithreading issues. Nice, but completely wrong. STM in Tomcat uses an instance pool which allows having a minimal impact (something like 5%), and it will perform much better than syncing, unless the said sync is trivial. Completely wrong? Actually taken from servlet spec 2.5 draft, but I guess it's not changed since 2.4. SRV.2.2.1 Note About The Single Thread Model The use of the SingleThreadModel interface guarantees that only one thread at a time will execute in a given servlet instance’s service method. It is important to note that this guarantee only applies to each servlet instance, since the container may choose to pool such objects. Objects that are accessible to more than one servlet instance at a time, such as instances of HttpSession, may be available at any particular time to multiple servlets, including those that implement SingleThreadModel. It is recommended that a developer take other means to resolve those issues instead of implementing this interface, such as avoiding the usage of an instance variable or synchronizing the block of the code accessing those resources. The SingleThreadModel Interface is deprecated in this version of the specification. Probably I mis-understood what guarantee only applies to 'each' servlet instance, since the container may choose to pool such objects. In how far this is good for performance reasons, I cannot judge, never tried for above reasons. The reason this is deprecated is because some people thought it would solve all their syncing problems, while it doesn't address many things (like session access). true indeed, that's why I warned to use single thread model for an easy cure for all multithreading issues (especially if a DB access is intendend). Cheers, Michael -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please help, i have to be missing something very simple
Randy Paries wrote: I created a little test program(see below), and i get the following error java com.unitnet.utils.testcolor Just Before Exception in thread main java.lang.UnsatisfiedLinkError: /usr/java/j2sdk1.4.2_04/jre/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1560) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1477) at java.lang.Runtime.loadLibrary0(Runtime.java:788) at java.lang.System.loadLibrary(System.java:834) at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50) at java.security.AccessController.doPrivileged(Native Method) at java.awt.Toolkit.loadLibraries(Toolkit.java:1437) at java.awt.Toolkit.clinit(Toolkit.java:1458) at java.awt.Color.clinit(Color.java:250) at com.unitnet.utils.testcolor.main(testcolor.java:13) This is not a Tomcat issue. Seems to be OS Java related, google is your friend. http://www.orablogs.com/duffblog/archives/2005_03.html search for /usr/java/j2sdk1.4.2_04/jre/lib/i386/libawt.so Maybe this helps where to look for, also if your server would have no graphics card don't forget to run java in headless mode when using awt. Cheers, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single Thread is deprecated?
Duan, Nick wrote: HttpServlet is inherently thread-safe as long as you don't use any instance and class variables in your code. There is also no need to sync around the session object, because there is only one servlet that is active at a time. The only sync you have to do is with app context objects. How can you guarantee that only one servlet is active at a time? Tomcat by default has many connector threads that could simultaneously handle concurrent requests to the same servlet or different servlets that all could work with the same sessionid session objects. Without SingleThreadModel this servlet won't be pooled, hence all requests would have to be serialized to make this work, which is obviously not an option for performance reasons as the spec says (e.g. regarding servlet lifecycle and synchronized service methods) BTW, if only one servlet would be active at a time, your advice not to use instance/class variables would not be of any use, as under this assumption no concurrency issues while accessing those variables could occur. However it's valid. It should be quite easy to write a simple test jsp using a session and containing e.g. image links to a servlet that manipulates session content, each time called. Due to most browsers behaviour to request many images at the same time and Tomcats connector threads, I wouldn't bet on this, if you put this under load and log results... If you want to sync on your DB resource, you will have bottleneck problems with DB connections. The best solution is to use a DB connection pool which is more scalable. DB connections pools are a good idea (e.g. to avoid connection opening times that take a few hundred ms with most DBs, eventhough neglectable for others). Nevertheless depending on the kind of transactions done, setting an appropriate transaction isolation level is just as important as doing other syncs. If you just read from the DB you can stick to the default level, but e.g. for a booking reservation system, I wouldn't trust read-committed, when doing lookups, inserts, updates wildly mixed in one transaction. Could easily happen that someone else booked your trip then, eventhough you got the confirmation... ;-) Cheers, Michael ND -Original Message- From: Michael Echerer [mailto:[EMAIL PROTECTED] Sent: Friday, January 06, 2006 11:52 AM To: Tomcat Users List Subject: Re: Single Thread is deprecated? Christian Stalp wrote: Hello out there, I want to build a servelt which access a database. To avoid race-conditions and to realize synchronous access, I decited to make a Singe Thread Servlet. But Eclipse told me that this is no longer a usable code. Usually the best solution is to synchronize just the part that accesses the single resource (the DB) instead of using single thread. In worst case you won't even achieve what you want using single thread mode because according to the servlet specification servlet containers are free to pool servlets, if it implements SingleThreadModel. Hence you could have multiple pooled instances that be no means guarantee an synchronized access to your database in case of simultaneous requests hitting different instances. So SingleThreadModel is deprecated for good reason, since servlet spec 2.4 and also for 2.5. You are better of synchronizing yourself. Don't rely on SingleThreadModel as an easy way to get around multithreading issues. In case you have different code parts accessing your DB or various clients, it might not even help to just sync one servlet. You might even have to set database transaction isolation level to fit your needs for your DB connections. Most DBs have read-committed by default, but it might be that you need isolation level up to synchronized. Depends on your use case... Cheers Michael So what can I do else? Thank you... Gruss Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
