Exexting threads in Tomcat
Hi All, I am using JSF framework for my project. I don't know if Tomcat is restcting me or JSF framework is restricting me. But I am unable to create and execute threads either in my JSF pages or my managed beans. I have created and exected threads successfully in this http://www.mystudentapartments.com There I have used normal JSPs But I am facing problem on this in my current project. Please help Thanks Sudhakar
Executing threads in Tomcat
Hi All, I am using JSF framework for my project. I don't know if Tomcat is restcting me or JSF framework is restricting me. But I am unable to create and execute threads either in my JSF pages or my managed beans. I have created and exected threads successfully in this http://www.mystudentapartments.com There I have used normal JSPs But I am facing problem on this in my current project. Please help Thanks Sudhakar
threads in tomcat
Hello, If I use threads, through the Thread class, how can I can finish them whenever Tomcat reloads the application that created them. Thanks. Regards. Daniel Molina Wegener - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: threads in tomcat
You should hold a reference to your thread in your app. Set a flag that the thread watches to notify it that it is time to terminate. Place this code in the servlet's destroy() body. Calling the destroy() on the thread object is a little drastic because it will terminate the thread without calling cleanup methods. Thread.stop() is deprecated because it does not clean up well either. Robert S. Harper Information Access Technology, Inc. -Original Message- From: Daniel Molina (Inter-Media) [mailto:[EMAIL PROTECTED] Sent: Thursday, June 16, 2005 10:29 AM To: Tomcat Users Subject: threads in tomcat Hello, If I use threads, through the Thread class, how can I can finish them whenever Tomcat reloads the application that created them. Thanks. Regards. Daniel Molina Wegener - 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: threads in tomcat
From: Daniel Molina (Inter-Media) [EMAIL PROTECTED] If I use threads, through the Thread class, how can I can finish them whenever Tomcat reloads the application that created them. You can use a ServletContextListener which will be notified when the webapp starts and stops. Implement the 'contextDestroyed' method, and do your cleanup there. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Threads in Tomcat 5
Hello all, I'm a newbie in mailing user list. My post is relationship with threads in Tomcat Server 5.0. Over Debian Linux v3.0 rc 2, threads are shown like processes; many processes are shown in process list command (ps -aux). We think that most of them, except one or two are threads, are depending of one process (JVM). When Tomcat starts up, several processes (threads in reality) rise up; but totally number is bigger than the parameters specified in server.xml. In this file (server.xml) parameters like maxThreads, minSpareThreads, maxSpareThreads are used to sign the maximum and the minimum processes in the JVM. In fact, when we see the process list, process count is larger than the value of these parameters. Are there any solution about limit the process or threads count?. Remember that Tomcat server.xml parameters don`t work. Thanks very much.
AW: Threads in Tomcat 5
Hi Are there any solution about limit the process or threads count?. Remember that Tomcat server.xml parameters don`t work. For me, these settings work. However, remember what they describe. They set the numbers of workers, not total threads. You applicaton might spawn threads, tomcat might spawn daemon threads, even the vm might spawn threads (gc such). You cannot limit anything other then worker threads. However, tomcat and the vm will only spawn a very few daemon threads and you have control over your application. Regards, Steffen smime.p7s Description: S/MIME cryptographic signature
RE: stopping all the java threads when tomcat stops
Yoav, Thank you, we tried to stop using scheduler.shutdown method in quartz servlet's destroy method but it is not working as expected. Also I would like to clarify one more doubt when load-on-startup method called will it call init method of the servlet all the time.ie. Even when tomcat remove the servlet when it is not used for long time and again calls back when load increased. -Jignesh On Wed, 2004-08-11 at 09:30, Shapira, Yoav wrote: Hi, Years ago, I posted a SystemThreadList class to the mailing list: search the archives. It will let you access and stop any thread in your JVM. Of course if you're running with a security manager, you would need to configure the policy file appropriately. However, instead of doing this brute-force approach, try looking for a Quartz shutdown method that will stop all its threads more gracefully. In fact, a casual glance at the JavaDoc shows Scheduler#shutdown which should do what you want. Yoav Shapira Millennium Research Informatics -Original Message- From: Jignesh Patel [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 11, 2004 6:58 PM To: Tomcat Users List Subject: stopping all the java threads when tomcat stops Hi All, As on previous topic we discussed for developing listener to stop the application. Now our confusion is we are using quartz application with tomcat, so when we stop the tomcat it never stops. We want to develop a listener which listens on stopping the server and in turn stops all the running threads. We used garbage collector and context listener but we couldn't able to do it. Any suggestion appreciated in this topic. -Jignesh - 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]
Re: stopping all the java threads when tomcat stops
On Thu, Aug 12, 2004 at 11:57:04AM -0400, Jignesh Patel wrote: : Thank you, we tried to stop using scheduler.shutdown method in quartz : servlet's destroy method but it is not working as expected. You *really* want to use a ContextListener for this: it provides the equivalents of a servlet's init() and destroy() but for the entire webapp. In turn, those are only called when the webapp is activated and deactivated, for lack of better terminology. ;) : Also I would like to clarify one more doubt when load-on-startup method : called will it call init method of the servlet all the time.ie. Even : when tomcat remove the servlet when it is not used for long time and : again calls back when load increased. Servlet#init() Called by the servlet container to indicate to a servlet that the servlet is being placed into service. The servlet container calls the init method exactly once after instantiating the servlet. The init method must complete successfully before the servlet can receive any requests. The servlet container cannot place the servlet into service if the init method (J2EE docs) So if a servlet is taken in and out of service during a context's runtime... -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
stopping all the java threads when tomcat stops
Hi All, As on previous topic we discussed for developing listener to stop the application. Now our confusion is we are using quartz application with tomcat, so when we stop the tomcat it never stops. We want to develop a listener which listens on stopping the server and in turn stops all the running threads. We used garbage collector and context listener but we couldn't able to do it. Any suggestion appreciated in this topic. -Jignesh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: stopping all the java threads when tomcat stops
Hi, Years ago, I posted a SystemThreadList class to the mailing list: search the archives. It will let you access and stop any thread in your JVM. Of course if you're running with a security manager, you would need to configure the policy file appropriately. However, instead of doing this brute-force approach, try looking for a Quartz shutdown method that will stop all its threads more gracefully. In fact, a casual glance at the JavaDoc shows Scheduler#shutdown which should do what you want. Yoav Shapira Millennium Research Informatics -Original Message- From: Jignesh Patel [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 11, 2004 6:58 PM To: Tomcat Users List Subject: stopping all the java threads when tomcat stops Hi All, As on previous topic we discussed for developing listener to stop the application. Now our confusion is we are using quartz application with tomcat, so when we stop the tomcat it never stops. We want to develop a listener which listens on stopping the server and in turn stops all the running threads. We used garbage collector and context listener but we couldn't able to do it. Any suggestion appreciated in this topic. -Jignesh - 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]
Threads in Tomcat 5
Hi, I'm trying to understand how exactly Tomcat 5 is organized to work with threads. Is there any documentation on how the connector is using the threads? What happens in the thread pool, how exactly the are threads picked from the pool and what is their state? And what happens with the released threads? Our login application is having problems when retrieving data from the requests. I was debugging the process by printing out the current thread name and the request parameter values. Everything works fine when there is a different thread assigned to each request: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor22 When an old thread is used for the new request, things don't work (usually the wrong parameter values are returned) and the debug output looks like this: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor25 Our application uses ThreadLocal to create a Hashtable with the current request parameters as a cache storage. Very often the same thread is used for more than one requests, the parameter values are retrieved from the cache instead of using the new values. This completely breaks the logic and the login process fails. Thanks, Ross This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution.
RE: Threads in Tomcat 5
Hi, The same thread may be used for the container to handle multiple requests, though of course not concurrently. Any other behavior doesn't scale so it doesn't make sense ;) I suggest you change your login logic. As for docs, what you're really looking for is source code, which is of course available. Yoav Shapira Millennium Research Informatics -Original Message- From: Angelov, Rossen [mailto:[EMAIL PROTECTED] Sent: Thursday, April 01, 2004 11:27 AM To: 'Tomcat Users List' Subject: Threads in Tomcat 5 Hi, I'm trying to understand how exactly Tomcat 5 is organized to work with threads. Is there any documentation on how the connector is using the threads? What happens in the thread pool, how exactly the are threads picked from the pool and what is their state? And what happens with the released threads? Our login application is having problems when retrieving data from the requests. I was debugging the process by printing out the current thread name and the request parameter values. Everything works fine when there is a different thread assigned to each request: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor22 When an old thread is used for the new request, things don't work (usually the wrong parameter values are returned) and the debug output looks like this: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor25 Our application uses ThreadLocal to create a Hashtable with the current request parameters as a cache storage. Very often the same thread is used for more than one requests, the parameter values are retrieved from the cache instead of using the new values. This completely breaks the logic and the login process fails. Thanks, Ross This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution. This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Threads in Tomcat 5
why do you want to use a thread to manage authentication? given the requestProcessor threads are reused, it makes no sense to use the thread for the mapping. you're better off just authenticating the first time and setting the HttpSession, rather than look up the thread. I'm probably missing something. peter Angelov, Rossen [EMAIL PROTECTED] wrote: Hi, I'm trying to understand how exactly Tomcat 5 is organized to work with threads. Is there any documentation on how the connector is using the threads? What happens in the thread pool, how exactly the are threads picked from the pool and what is their state? And what happens with the released threads? Our login application is having problems when retrieving data from the requests. I was debugging the process by printing out the current thread name and the request parameter values. Everything works fine when there is a different thread assigned to each request: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor22 When an old thread is used for the new request, things don't work (usually the wrong parameter values are returned) and the debug output looks like this: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor25 Our application uses ThreadLocal to create a Hashtable with the current request parameters as a cache storage. Very often the same thread is used for more than one requests, the parameter values are retrieved from the cache instead of using the new values. This completely breaks the logic and the login process fails. Thanks, Ross This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution. - Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today
RE: Threads in Tomcat 5
Well, the login requirements are not that simple to explain in few lines. Some pages require authentication some don't, so it won't be appropriate to do this when the HttpSession is first started. ThreadLocal is used to identify the current thread (assuming that's for the current request) to get the request parameters and create a hashtable for caching purpose (this was done to speed up the registration process where over 30 demographic fields are passed between pages). The same logic is used when logging in or uploading a file with MultipartRequest. The applications were originally created 2-3 years ago to work on iPlanet and now I'm trying move them to Tomcat but it looks like there will be lot of problems. Ross -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Thursday, April 01, 2004 11:21 AM To: Tomcat Users List Subject: Re: Threads in Tomcat 5 why do you want to use a thread to manage authentication? given the requestProcessor threads are reused, it makes no sense to use the thread for the mapping. you're better off just authenticating the first time and setting the HttpSession, rather than look up the thread. I'm probably missing something. peter Angelov, Rossen [EMAIL PROTECTED] wrote: Hi, I'm trying to understand how exactly Tomcat 5 is organized to work with threads. Is there any documentation on how the connector is using the threads? What happens in the thread pool, how exactly the are threads picked from the pool and what is their state? And what happens with the released threads? Our login application is having problems when retrieving data from the requests. I was debugging the process by printing out the current thread name and the request parameter values. Everything works fine when there is a different thread assigned to each request: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor22 When an old thread is used for the new request, things don't work (usually the wrong parameter values are returned) and the debug output looks like this: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor25 Our application uses ThreadLocal to create a Hashtable with the current request parameters as a cache storage. Very often the same thread is used for more than one requests, the parameter values are retrieved from the cache instead of using the new values. This completely breaks the logic and the login process fails. Thanks, Ross This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution. - Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution.
RE: Threads in Tomcat 5
Have you considered using the HttpSession ID as the key for the hashtable instead? I forget if the httpsession id implementation has changed or not. Even though the session ID is not guaranteed to be unique, it practically is unique if user sessions are relatively short and don't last hours or days. your other option is to generate an absolutely unique key and set it in the HttpSession, and use your unique key for the map. I'm sure there are other options. peter Angelov, Rossen [EMAIL PROTECTED] wrote: Well, the login requirements are not that simple to explain in few lines. Some pages require authentication some don't, so it won't be appropriate to do this when the HttpSession is first started. ThreadLocal is used to identify the current thread (assuming that's for the current request) to get the request parameters and create a hashtable for caching purpose (this was done to speed up the registration process where over 30 demographic fields are passed between pages). The same logic is used when logging in or uploading a file with MultipartRequest. The applications were originally created 2-3 years ago to work on iPlanet and now I'm trying move them to Tomcat but it looks like there will be lot of problems. Ross -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Thursday, April 01, 2004 11:21 AM To: Tomcat Users List Subject: Re: Threads in Tomcat 5 why do you want to use a thread to manage authentication? given the requestProcessor threads are reused, it makes no sense to use the thread for the mapping. you're better off just authenticating the first time and setting the HttpSession, rather than look up the thread. I'm probably missing something. peter Angelov, Rossen wrote: Hi, I'm trying to understand how exactly Tomcat 5 is organized to work with threads. Is there any documentation on how the connector is using the threads? What happens in the thread pool, how exactly the are threads picked from the pool and what is their state? And what happens with the released threads? Our login application is having problems when retrieving data from the requests. I was debugging the process by printing out the current thread name and the request parameter values. Everything works fine when there is a different thread assigned to each request: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor22 When an old thread is used for the new request, things don't work (usually the wrong parameter values are returned) and the debug output looks like this: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor25 Our application uses ThreadLocal to create a Hashtable with the current request parameters as a cache storage. Very often the same thread is used for more than one requests, the parameter values are retrieved from the cache instead of using the new values. This completely breaks the logic and the login process fails. Thanks, Ross This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution. - Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution. - Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today
RE: Threads in Tomcat 5
hit send too soon. Another approach which I've used and is common is to have the notion of access control privledge like Unix file privledges. Each page has a set privledge level and once the user is authenticated, the page checks the users access level. there are numerous other variations on this for single-sign-on applications. peter Angelov, Rossen [EMAIL PROTECTED] wrote: Well, the login requirements are not that simple to explain in few lines. Some pages require authentication some don't, so it won't be appropriate to do this when the HttpSession is first started. ThreadLocal is used to identify the current thread (assuming that's for the current request) to get the request parameters and create a hashtable for caching purpose (this was done to speed up the registration process where over 30 demographic fields are passed between pages). The same logic is used when logging in or uploading a file with MultipartRequest. The applications were originally created 2-3 years ago to work on iPlanet and now I'm trying move them to Tomcat but it looks like there will be lot of problems. Ross -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Thursday, April 01, 2004 11:21 AM To: Tomcat Users List Subject: Re: Threads in Tomcat 5 why do you want to use a thread to manage authentication? given the requestProcessor threads are reused, it makes no sense to use the thread for the mapping. you're better off just authenticating the first time and setting the HttpSession, rather than look up the thread. I'm probably missing something. peter Angelov, Rossen wrote: Hi, I'm trying to understand how exactly Tomcat 5 is organized to work with threads. Is there any documentation on how the connector is using the threads? What happens in the thread pool, how exactly the are threads picked from the pool and what is their state? And what happens with the released threads? Our login application is having problems when retrieving data from the requests. I was debugging the process by printing out the current thread name and the request parameter values. Everything works fine when there is a different thread assigned to each request: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor22 When an old thread is used for the new request, things don't work (usually the wrong parameter values are returned) and the debug output looks like this: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor25 Our application uses ThreadLocal to create a Hashtable with the current request parameters as a cache storage. Very often the same thread is used for more than one requests, the parameter values are retrieved from the cache instead of using the new values. This completely breaks the logic and the login process fails. Thanks, Ross This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution. - Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution. - Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today
RE: Threads in Tomcat 5
I'll consider the HttpSession as an option and will implement sorting to see if it work for us. I'm not sure what you mean by single-sign-on application but our authentication system uses a eRights, a product of eMETA, to authenticate users and give access only to certain resources (usually pages) based on the product and the policy information. Each http session is related to an eRights session. Ross -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Thursday, April 01, 2004 12:26 PM To: Tomcat Users List Subject: RE: Threads in Tomcat 5 hit send too soon. Another approach which I've used and is common is to have the notion of access control privledge like Unix file privledges. Each page has a set privledge level and once the user is authenticated, the page checks the users access level. there are numerous other variations on this for single-sign-on applications. peter Angelov, Rossen [EMAIL PROTECTED] wrote: Well, the login requirements are not that simple to explain in few lines. Some pages require authentication some don't, so it won't be appropriate to do this when the HttpSession is first started. ThreadLocal is used to identify the current thread (assuming that's for the current request) to get the request parameters and create a hashtable for caching purpose (this was done to speed up the registration process where over 30 demographic fields are passed between pages). The same logic is used when logging in or uploading a file with MultipartRequest. The applications were originally created 2-3 years ago to work on iPlanet and now I'm trying move them to Tomcat but it looks like there will be lot of problems. Ross -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Thursday, April 01, 2004 11:21 AM To: Tomcat Users List Subject: Re: Threads in Tomcat 5 why do you want to use a thread to manage authentication? given the requestProcessor threads are reused, it makes no sense to use the thread for the mapping. you're better off just authenticating the first time and setting the HttpSession, rather than look up the thread. I'm probably missing something. peter Angelov, Rossen wrote: Hi, I'm trying to understand how exactly Tomcat 5 is organized to work with threads. Is there any documentation on how the connector is using the threads? What happens in the thread pool, how exactly the are threads picked from the pool and what is their state? And what happens with the released threads? Our login application is having problems when retrieving data from the requests. I was debugging the process by printing out the current thread name and the request parameter values. Everything works fine when there is a different thread assigned to each request: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor22 When an old thread is used for the new request, things don't work (usually the wrong parameter values are returned) and the debug output looks like this: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor25 Our application uses ThreadLocal to create a Hashtable with the current request parameters as a cache storage. Very often the same thread is used for more than one requests, the parameter values are retrieved from the cache instead of using the new values. This completely breaks the logic and the login process fails. Thanks, Ross This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution. - Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution. - Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution.
RE: Threads in Tomcat 5
Ok, here's a quick overview of single-sign-on applications. It's prevalent in large platforms and large corporations. Say for example you're a bank and you have several branches. Each branch has their own IT department and divisions. The pages users can view depend on their level of access privledge. In the typical single-sign-on application I am familiar with, the user only has to sign on once. Normally this is done with LDAP or some kind of directory server. Basically, the database (rdbms or ldap) contains information about what pages, sites and privledges the user has. User joe signs on to the bank, but he also has an account with the IRA retirement department of the bank. When Joe clicks on the link to see his IRA, it automatically sends a kerberos like session token to the other system and redirects the user. To Joe, it all looks seamless, but in reality he has been transferred from one system to another. User bob signs on to see his account, but if Bob doesn't have an IRA account the system directs him to sign up for an IRA. It sounds like you don't need this level of complexity, but the principle is the same. There are n pages, each with privledge requirements. If your pages already have the notion of access privledges, the authentication portion becomes very simple. Otherwise retrofitting the website becomes a tedious process. I hope that helps. peter Angelov, Rossen [EMAIL PROTECTED] wrote: I'll consider the HttpSession as an option and will implement sorting to see if it work for us. I'm not sure what you mean by single-sign-on application but our authentication system uses a eRights, a product of eMETA, to authenticate users and give access only to certain resources (usually pages) based on the product and the policy information. Each http session is related to an eRights session. Ross -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Thursday, April 01, 2004 12:26 PM To: Tomcat Users List Subject: RE: Threads in Tomcat 5 hit send too soon. Another approach which I've used and is common is to have the notion of access control privledge like Unix file privledges. Each page has a set privledge level and once the user is authenticated, the page checks the users access level. there are numerous other variations on this for single-sign-on applications. peter Angelov, Rossen wrote: Well, the login requirements are not that simple to explain in few lines. Some pages require authentication some don't, so it won't be appropriate to do this when the HttpSession is first started. ThreadLocal is used to identify the current thread (assuming that's for the current request) to get the request parameters and create a hashtable for caching purpose (this was done to speed up the registration process where over 30 demographic fields are passed between pages). The same logic is used when logging in or uploading a file with MultipartRequest. The applications were originally created 2-3 years ago to work on iPlanet and now I'm trying move them to Tomcat but it looks like there will be lot of problems. Ross -Original Message- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Thursday, April 01, 2004 11:21 AM To: Tomcat Users List Subject: Re: Threads in Tomcat 5 why do you want to use a thread to manage authentication? given the requestProcessor threads are reused, it makes no sense to use the thread for the mapping. you're better off just authenticating the first time and setting the HttpSession, rather than look up the thread. I'm probably missing something. peter Angelov, Rossen wrote: Hi, I'm trying to understand how exactly Tomcat 5 is organized to work with threads. Is there any documentation on how the connector is using the threads? What happens in the thread pool, how exactly the are threads picked from the pool and what is their state? And what happens with the released threads? Our login application is having problems when retrieving data from the requests. I was debugging the process by printing out the current thread name and the request parameter values. Everything works fine when there is a different thread assigned to each request: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor22 When an old thread is used for the new request, things don't work (usually the wrong parameter values are returned) and the debug output looks like this: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor25 Our application uses ThreadLocal to create a Hashtable with the current request parameters as a cache storage. Very often the same thread is used for more than one requests, the parameter values are retrieved from the cache instead of using the new values. This completely breaks the logic and the login process fails. Thanks, Ross This communication
RE: Threads in Tomcat 5
Tomcat uses a ThreadPool so Threads are recycled. If you store something in a ThreadLocal it it your resposibility to clear the stored values at the end of the use. So if you store request variables you have to clear them at the end of the request (or before storing them at the beginning of the request). Sadly the the ThreadLocal API has no means to clear the state for a thread easily. To clear it, you have to know what is stored in ThreadLocals. But as you describe your application that shouldn't cause a problem. -Original Message- From: Angelov, Rossen [mailto:[EMAIL PROTECTED] Sent: Thursday, April 01, 2004 6:27 PM To: 'Tomcat Users List' Subject: Threads in Tomcat 5 Hi, I'm trying to understand how exactly Tomcat 5 is organized to work with threads. Is there any documentation on how the connector is using the threads? What happens in the thread pool, how exactly the are threads picked from the pool and what is their state? And what happens with the released threads? Our login application is having problems when retrieving data from the requests. I was debugging the process by printing out the current thread name and the request parameter values. Everything works fine when there is a different thread assigned to each request: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor22 When an old thread is used for the new request, things don't work (usually the wrong parameter values are returned) and the debug output looks like this: request 1 current thread: http8080-Processor25 request 2 current thread: http8080-Processor23 request 3 current thread: http8080-Processor25 Our application uses ThreadLocal to create a Hashtable with the current request parameters as a cache storage. Very often the same thread is used for more than one requests, the parameter values are retrieved from the cache instead of using the new values. This completely breaks the logic and the login process fails. Thanks, Ross This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Threads in Tomcat
Thanks to All, I have done all the stuff to make my web app thread safe,
It seems its fine for the moment.Except for a few more things.
It seems threading is realy complex. I am forking out a new thread in my
Handle request method and this is making the other request to wait for
the other thread to complete.
Actualy what is happening is this I have this code , I am using Velocity
public Template handleRequest( HttpServletRequest request,
HttpServletResponse response, Context context )
{
...
...
someCode1;
gmh=new MyThread();
new Thread(gmh).start();
someCode2;
}
when two clients make a request ,suppose client1 makes a request then
manages to start the thread first then client2 makes a request while
client1 thread has already started running ,client2 will somehow be
forced to wait on someCode1 until client1 thread has finished .Can you
imagine if client1 takes a very long time to finish,that means client2
will also take a very long time
I do not think it should do this
I was thinking of using a thread pool, now I need some example code to
use a thread pool havent got any idea were to start, just some pointers
to help me ,dont want to give you too much trouble :-)
Thanks in advance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
creating threads in tomcat
Hi all; I realize this is a 'complex' (for me at least) question, but maybe someone can give me their opinion on it. I am using Tomcat 5 for my webapp which allows insertion of messages (and much more). I also need to have an independent 'engine' that will look into DB and 'handle' newly inserted messages. This engine will, depending on the type of message, do a specific task. This will require arround 7 new threads that I will control (hopefully). Among other things I will need to read information from database in these new threads. I feel like I have 3 choices: 1. Implement my engine in Tomcat JVM. 2. Implement it in a JVM outside Tomcat and communicate with the webapp only thru DB. (so almost have 2 independent apps that use the same DB) 3. Implement it in a JVM outside Tomcat and communicate with Tomcat JVM thru RMI. I like 1. because all would be in one place, and I would use DB connection pooling provided by Tomcat. I like 2. because I understand it is bad to open new threads in Tomcat. I like 3 because I avoid having threads in Tomcat, but can get to DB thru classes that are already in my Tomcat JVM via RMI. I do not like it because it is more complex. ** So I have one question: ** 1. How bad (what performance hit, and other negative aspects should I expect) is it to open new threads in Tomcat, and arround 7 of them. and I wonder if someone can point me or suggest to me to a solution, article, discussion or anything about this little problem that I have. Sincerely and thankfully Damjan _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: creating threads in tomcat
Howdy, 1. Implement my engine in Tomcat JVM. 2. Implement it in a JVM outside Tomcat and communicate with the webapp only thru DB. (so almost have 2 independent apps that use the same DB) 3. Implement it in a JVM outside Tomcat and communicate with Tomcat JVM thru RMI. I like 1. because all would be in one place, and I would use DB connection pooling provided by Tomcat. It's also good because you will be able to easily monitor and manage the DB threads via a web interface if you'd like. I like 2. because I understand it is bad to open new threads in Tomcat. You understand incorrectly. It's not bad to start new threads in tomcat. It's bad to start badly-written threads. When you use your own threads, either make them daemons or make sure they terminate properly when your webapp shuts down. The performance overhead of creating and running 7 threads is negligible on a modern machine and JVM. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HOW CAN I USE THREADS IN TOMCAT
Hello, Prince! You wrote to Tomcat Users List [EMAIL PROTECTED] on Sat, 1 Nov 2003 13:21:42 +0530: P Hi, P I need to send a mail automatically at 10 minutes interval. how can P i do this? how can i activate threads in tomcat? Tomcat is a Java application, there are no difference of using threads with Tomcat or without it. Simply expand Thread class, and run your thread. But don't forget to notify and kill your thread when Tomcat is shutting down. Here is a link that might help you. http://developer.java.sun.com/developer/codesamples/thrds.html --- Regards Ivan[a]yourmail.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HOW CAN I USE THREADS IN TOMCAT
Hi, I have an instance of MyMailScheduler - mmsched in a ContextListener class for my webapp. mmsched spawns threads to do some work regarding sending emails. In my contextDestroy method I do : mmsched = null; I was under the impression that if tomcat was shutdown or the webapp was stopped my threads would be automatically killed since mmsched would be garbage collected. Am I understanding this right or do I need to do something else ? My webapp does two mail related tasks for two different sets of data. Both tasks are identical and therefore I spawn two threads. The two threads do not share any data structures. Also do I need to make the run() method synchronized ? Thanks. On Monday, November 3, 2003, at 08:45 PM, IvanLatysh wrote: Hello, Prince! You wrote to Tomcat Users List [EMAIL PROTECTED] on Sat, 1 Nov 2003 13:21:42 +0530: P Hi, P I need to send a mail automatically at 10 minutes interval. how can P i do this? how can i activate threads in tomcat? Tomcat is a Java application, there are no difference of using threads with Tomcat or without it. Simply expand Thread class, and run your thread. But don't forget to notify and kill your thread when Tomcat is shutting down. Here is a link that might help you. http://developer.java.sun.com/developer/codesamples/thrds.html --- Regards Ivan[a]yourmail.com - 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: HOW CAN I USE THREADS IN TOMCAT
Hi, The problem is that stop / suspend are deprecated. The destroy() method has yet not been implemented ? What does one do then? I have a solution - Keep a reference to the instances of the threads spawned in a hashtable. In contextDestroy make all these references null . Will this solution work ? Thanks. On Monday, November 3, 2003, at 09:27 PM, Shapira, Yoav wrote: Howdy, I have an instance of MyMailScheduler - mmsched in a ContextListener class for my webapp. mmsched spawns threads to do some work regarding sending emails. In my contextDestroy method I do : mmsched = null; mmsched should have a close()/stop()/shutdown() method which stops its threads. You call this method, and then set mmsched to null. I was under the impression that if tomcat was shutdown or the webapp was stopped my threads would be automatically killed since mmsched would be garbage collected. Am I understanding this right or do I need to do something else ? The JVM can't stop non-daemon threads. Either make mmsched spawn daemon threads, or make the mmsched stop() method interrupt and stop all its threads. My webapp does two mail related tasks for two different sets of data. Both tasks are identical and therefore I spawn two threads. The two threads do not share any data structures. Also do I need to make the run() method synchronized ? You don't need to make the run() method synchronized. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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]
HOW CAN I USE THREADS IN TOMCAT
Hi, I need to send a mail automatically at 10 minutes interval. how can i do this? how can i activate threads in tomcat? regards Prince - Original Message - From: Bill Barker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 01, 2003 1:00 PM Subject: Re: Opinions The recent port of the 3.3 variable-substitution to Tomcat 5 may very well solve your problems here :). The ports are supposed to move to commons-digester, so should be available in 4.1.30 as well. Francois JEANMOUGIN [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hu! It's in early developments or is it suitable for production ? It's ready for production. People are already using it in production with tomcat 5. Of course, I'm biased ;) Well, there is that beta flag in front of tomcat5 that tell me that your opinion is more than biased :). Of course, I saw a mail telling that the beta flag is related to specification instability (not code), anyway... It's a Developer, rather than Sysadmin, option. Chances are you won't need to worry about it as you'll use commons-daemon with tomcat, which already does the required jsvc invocation for you. Well, that does not help that much. I hope that there will be a configuration scheme that'll let easily define user/group/port and so on for the connectors. Just waiting for a sysadmin point of view :). Thanks, François. - 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: HOW CAN I USE THREADS IN TOMCAT
Use cron under unix and/or a java app that would use Javamail classes. Of course you can do it inside a servlet. - Original Message - From: Prince [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Saturday, November 01, 2003 8:51 AM Subject: HOW CAN I USE THREADS IN TOMCAT Hi, I need to send a mail automatically at 10 minutes interval. how can i do this? how can i activate threads in tomcat? regards Prince - Original Message - From: Bill Barker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 01, 2003 1:00 PM Subject: Re: Opinions The recent port of the 3.3 variable-substitution to Tomcat 5 may very well solve your problems here :). The ports are supposed to move to commons-digester, so should be available in 4.1.30 as well. Francois JEANMOUGIN [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hu! It's in early developments or is it suitable for production ? It's ready for production. People are already using it in production with tomcat 5. Of course, I'm biased ;) Well, there is that beta flag in front of tomcat5 that tell me that your opinion is more than biased :). Of course, I saw a mail telling that the beta flag is related to specification instability (not code), anyway... It's a Developer, rather than Sysadmin, option. Chances are you won't need to worry about it as you'll use commons-daemon with tomcat, which already does the required jsvc invocation for you. Well, that does not help that much. I hope that there will be a configuration scheme that'll let easily define user/group/port and so on for the connectors. Just waiting for a sysadmin point of view :). Thanks, François. - 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]
Re: HOW CAN I USE THREADS IN TOMCAT
A servlet is just a Java class. You can do anything you can do with the
java language, including start threads. The following starts a thread
that runs some task every 10 minutes. The thread is started in the
servlet init method. I choose to set the thread to daemon mode, meaning
that when the main thread of execution shuts down the mailer thread will
automatically be killed. Otherwise you need to be sure to keep track of
it and be sure to signal it to shutdown in your Servlet.destroy method.
public class MyServlet extends HttpServlet
{
private static class MailerThread extends Thread
{
public void run ()
{
while (true)
{
// do something
synchronized (this)
{
wait (10*60*1000);
}
}
}
}
// the servlet init method
public void init ()
{
MailerThread thread = new MailerThread ();
thread.setDaemon (true);
thread.start ();
}
// ... doGet, etc. ...
}
-Erik
Eric C wrote:
Use cron under unix and/or a java app that would use Javamail classes.
Of course you can do it inside a servlet.
- Original Message -
From: Prince [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Saturday, November 01, 2003 8:51 AM
Subject: HOW CAN I USE THREADS IN TOMCAT
Hi,
I need to send a mail automatically at 10 minutes interval. how can i do
this? how can i activate threads in tomcat?
regards
Prince
- Original Message -
From: Bill Barker [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, November 01, 2003 1:00 PM
Subject: Re: Opinions
The recent port of the 3.3 variable-substitution to Tomcat 5 may very
well
solve your problems here :). The ports are supposed to move to
commons-digester, so should be available in 4.1.30 as well.
Francois JEANMOUGIN [EMAIL PROTECTED] wrote in
message
news:[EMAIL PROTECTED]
Hu! It's in early developments or is it suitable for production ?
It's ready for production. People are already using it in production
with tomcat 5. Of course, I'm biased ;)
Well, there is that beta flag in front of tomcat5 that tell me that your
opinion is more than biased :). Of course, I saw a mail telling that the
beta flag is related to specification instability (not code), anyway...
It's a Developer, rather than Sysadmin, option. Chances are you won't
need to worry about it as you'll use commons-daemon with tomcat, which
already does the required jsvc invocation for you.
Well, that does not help that much. I hope that there will be a
configuration scheme that'll let easily define user/group/port and so on
for
the connectors. Just waiting for a sysadmin point of view :).
Thanks,
François.
-
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]
--
http://www.spectacle.ca/
The New Online Source for Live Music in Montreal
.::514.286.1699::.
RE: HOW CAN I USE THREADS IN TOMCAT
I would also add that unless you have a particular need to embed this in
a specific Servlet, it might make more sense to add this thread to a
context listener handler.
For example, if I wanted to send out email to 1000 people (not Spam, of
course! ;-) and I initiated this from within a Servlet, in this case I'd
add a thread to the Servlet and let the Servlet return while the email
was still going out. This assumes I handle any errors in some other way
than displaying the results on the page.
On the other hand, if I wanted to, perhaps, clean-up some temporary data
within a database every so often, and I wanted to include this
funcitonality within a Web app rather than in a separate application
that I run from the CL via Cron every now and then, I'd probably
implement this within a context listener handler so that the thread
starts up when the Web app starts up and continues utnil the Web app
shuts down.
Just a thought!
-Fred Whipple
iMagine Internet Services
-Original Message-
From: Erik Wright [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 01, 2003 11:03 AM
To: Tomcat Users List
Subject: Re: HOW CAN I USE THREADS IN TOMCAT
A servlet is just a Java class. You can do anything you can
do with the
java language, including start threads. The following starts a thread
that runs some task every 10 minutes. The thread is started in the
servlet init method. I choose to set the thread to daemon
mode, meaning
that when the main thread of execution shuts down the mailer
thread will
automatically be killed. Otherwise you need to be sure to
keep track of
it and be sure to signal it to shutdown in your
Servlet.destroy method.
public class MyServlet extends HttpServlet
{
private static class MailerThread extends Thread
{
public void run ()
{
while (true)
{
// do something
synchronized (this)
{
wait (10*60*1000);
}
}
}
}
// the servlet init method
public void init ()
{
MailerThread thread = new MailerThread ();
thread.setDaemon (true);
thread.start ();
}
// ... doGet, etc. ...
}
-Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Threads and tomcat
Hi, I'm trying to get some info on the lifespan of a thread in tomcat (4), can somebody point me to some documentation or help me out? Cheers, Josh -- [ Josh 'G' McDonald ][ 0415 784 825 ][ http://www.gfunk007.com/ ] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Threads and tomcat
The lifespan of a thread or request? -Tim Josh G wrote: Hi, I'm trying to get some info on the lifespan of a thread in tomcat (4), can somebody point me to some documentation or help me out? Cheers, Josh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Threads and tomcat
Tim Funk wrote: The lifespan of a thread or request? -Tim A thread. Like when does tomcat decide to create them, and when they're done servicing a request are they killed or simply put on hold back in the pool to wait for the next request? And if they're kept alive, how long before thet're cleaned up to avoid leaks? That sort of thing. Cheers, -Josh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Threads and tomcat
Ok. I don't know and wish not to know. (Prefer to see what the spec says with respect to threads and obey that) At a minimum, tomcat obeys the spec with respect to thread usage. Tomcat will create the number of threads needed to serve the requests concurrently up to the configured limit. (minProcessors and maxProcessors) As for shrinking the pool, I don't know if it gets done. It might be documented or someone else will answer that. All threads are recycled in a thread pool to serve requests so the same thread may serve requests to any number of users (but not at the same time). And the same user may have his requests served by a different thread for each request. Killing threads will not eliminate leaks. Needlessly keeping object references help create memory leaks. -Tim Josh G wrote: Tim Funk wrote: The lifespan of a thread or request? -Tim A thread. Like when does tomcat decide to create them, and when they're done servicing a request are they killed or simply put on hold back in the pool to wait for the next request? And if they're kept alive, how long before thet're cleaned up to avoid leaks? That sort of thing. Cheers, -Josh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re[2]: [Q] Is it safe to create threads in Tomcat web-apps?
Howdy, Don't use commons-pool for a thread pool. Use Doug Lea's concurrency library instead. I should add this do the commons-pool javadoc somewhere. Commons-pool is excellent for all types of pooling, but not threads, as the concurrency issues are difficult at best to overcome. Yoav Shapira Millennium ChemInformatics -Original Message- From: Anton Tagunov [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 1:37 AM To: Tomcat Users List Subject: Re[2]: [Q] Is it safe to create threads in Tomcat web-apps? Hello Srevilak! sgn However, if the three steps are IO-bound, using multiple threads to sgn run them concurrently can lead to a big improvement. One might also consider using some kind of thread pooler in this setting. Perhaps one could be crafted on top of jakarta-commons-pool -Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Q] Is it safe to create threads in Tomcat web-apps?
jcrontab works ok, it is modeled after the unix crontab entries. Best bet is to try it and see if it meets ones needs :) Anton Tagunov wrote: So, what John is speaking about - spending less effort on thread coding and using an existing solution (native Unix crontab) may also be pushing you to using it Java analog - jcrontab. That being said I have not even read a page on the jcrontab site, so I do not know if it's workable or buggy. -Anton - 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[2]: [Q] Is it safe to create threads in Tomcat web-apps?
Hello Riaan! RO (I have no idea what cron +wegt is???) As John has explained JT cron = scheduler Unix world I would add to this :-) And on the files (or directories involved is named crontab, see bellow) JT wget = command line HTTP/HTTPS client both Unix and Windows I just wanted to say that Kwok Peng Tuck [EMAIL PROTECTED] has mentioned http://jcrontab.sourceforge.net As the name of the project suggests it is an effort to provide cron (aka crontab) functionality in Java. So, what John is speaking about - spending less effort on thread coding and using an existing solution (native Unix crontab) may also be pushing you to using it Java analog - jcrontab. That being said I have not even read a page on the jcrontab site, so I do not know if it's workable or buggy. -Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: [Q] Is it safe to create threads in Tomcat web-apps?
Hello Srevilak! sgn However, if the three steps are IO-bound, using multiple threads to sgn run them concurrently can lead to a big improvement. One might also consider using some kind of thread pooler in this setting. Perhaps one could be crafted on top of jakarta-commons-pool -Anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Q] Is it safe to create threads in Tomcat web-apps?
I've mainly worked in BEA WebLogic before and from colleagues and other sources I have heard it is not recommended (and sometimes not allowed, some even said) to create threads in your application. Indeed, when the application went live in a multi-server clustered environment, we got very inconsistent results because of the threads, so we had to remove them. Question is, how safe is it to create threads in a Tomcat web-app? I would assume worker threads are ok, i.e. threads you create to do a specific task and then it terminates. When you are guaranteed the thread will terminate either because of an error or because the assigned task has been completed. But what about monitor threads, i.e. threads that does a Thread.sleep(x) for an hour, check some condition and goes back to sleep... some mechanism you implement to e.g. do a task on a hourly/daily/weekly base. You'd create the thread (and keep a handle to it) in either an InitServlet.init() and then Thread.interrupt() in the InitServlet.destroy(), or you can do it in an ApplicationListener (something like that) class which I think you can define in the web.xml. How else can you implement that (monitoring) in Tomcat? __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Q] Is it safe to create threads in Tomcat web-apps?
You can create threads all day in tomcat, but here are the importnatn things to consider: - WHY! Are threads really the correct solution? - If you create threads - what are their scope? Daemon, non-daemon? - If you create non-daemon threads - be prepared for the consequences such as the JVM not going away on tomcat shutdown unless you have taken the needed precautions. - If you create dameon only threads, be prepared for when tomcat shuts down and your daemon still has work to do because the JVM could exit before your thread is ready to complete its unit of work - WHY! Are threads really the correct solution? - And last but not least: WHY! Are threads really the correct solution? -Tim Riaan Oberholzer wrote: I've mainly worked in BEA WebLogic before and from colleagues and other sources I have heard it is not recommended (and sometimes not allowed, some even said) to create threads in your application. Indeed, when the application went live in a multi-server clustered environment, we got very inconsistent results because of the threads, so we had to remove them. Question is, how safe is it to create threads in a Tomcat web-app? I would assume worker threads are ok, i.e. threads you create to do a specific task and then it terminates. When you are guaranteed the thread will terminate either because of an error or because the assigned task has been completed. But what about monitor threads, i.e. threads that does a Thread.sleep(x) for an hour, check some condition and goes back to sleep... some mechanism you implement to e.g. do a task on a hourly/daily/weekly base. You'd create the thread (and keep a handle to it) in either an InitServlet.init() and then Thread.interrupt() in the InitServlet.destroy(), or you can do it in an ApplicationListener (something like that) class which I think you can define in the web.xml. How else can you implement that (monitoring) in Tomcat? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Q] Is it safe to create threads in Tomcat web-apps?
Well, that was part of my question if I cannot/don't implement daemon threads to do e.g. automatic daily tasks, what else? E.g, at the end of the day send an e-mail to a (real life) manager with a summary of the day's transactions something like that. Does Tomcat provide some sort of ActionEvent which you can configure to be fired every x milliseconds? --- Tim Funk [EMAIL PROTECTED] wrote: You can create threads all day in tomcat, but here are the importnatn things to consider: - WHY! Are threads really the correct solution? - If you create threads - what are their scope? Daemon, non-daemon? - If you create non-daemon threads - be prepared for the consequences such as the JVM not going away on tomcat shutdown unless you have taken the needed precautions. - If you create dameon only threads, be prepared for when tomcat shuts down and your daemon still has work to do because the JVM could exit before your thread is ready to complete its unit of work - WHY! Are threads really the correct solution? - And last but not least: WHY! Are threads really the correct solution? -Tim Riaan Oberholzer wrote: I've mainly worked in BEA WebLogic before and from colleagues and other sources I have heard it is not recommended (and sometimes not allowed, some even said) to create threads in your application. Indeed, when the application went live in a multi-server clustered environment, we got very inconsistent results because of the threads, so we had to remove them. Question is, how safe is it to create threads in a Tomcat web-app? I would assume worker threads are ok, i.e. threads you create to do a specific task and then it terminates. When you are guaranteed the thread will terminate either because of an error or because the assigned task has been completed. But what about monitor threads, i.e. threads that does a Thread.sleep(x) for an hour, check some condition and goes back to sleep... some mechanism you implement to e.g. do a task on a hourly/daily/weekly base. You'd create the thread (and keep a handle to it) in either an InitServlet.init() and then Thread.interrupt() in the InitServlet.destroy(), or you can do it in an ApplicationListener (something like that) class which I think you can define in the web.xml. How else can you implement that (monitoring) in Tomcat? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Q] Is it safe to create threads in Tomcat web-apps?
Hello Riaan, you might want to check out jcrontab. http://jcrontab.sourceforge.net Riaan Oberholzer wrote: Well, that was part of my question if I cannot/don't implement daemon threads to do e.g. automatic daily tasks, what else? E.g, at the end of the day send an e-mail to a (real life) manager with a summary of the day's transactions something like that. Does Tomcat provide some sort of ActionEvent which you can configure to be fired every x milliseconds? --- Tim Funk [EMAIL PROTECTED] wrote: You can create threads all day in tomcat, but here are the importnatn things to consider: - WHY! Are threads really the correct solution? - If you create threads - what are their scope? Daemon, non-daemon? - If you create non-daemon threads - be prepared for the consequences such as the JVM not going away on tomcat shutdown unless you have taken the needed precautions. - If you create dameon only threads, be prepared for when tomcat shuts down and your daemon still has work to do because the JVM could exit before your thread is ready to complete its unit of work - WHY! Are threads really the correct solution? - And last but not least: WHY! Are threads really the correct solution? -Tim Riaan Oberholzer wrote: I've mainly worked in BEA WebLogic before and from colleagues and other sources I have heard it is not recommended (and sometimes not allowed, some even said) to create threads in your application. Indeed, when the application went live in a multi-server clustered environment, we got very inconsistent results because of the threads, so we had to remove them. Question is, how safe is it to create threads in a Tomcat web-app? I would assume worker threads are ok, i.e. threads you create to do a specific task and then it terminates. When you are guaranteed the thread will terminate either because of an error or because the assigned task has been completed. But what about monitor threads, i.e. threads that does a Thread.sleep(x) for an hour, check some condition and goes back to sleep... some mechanism you implement to e.g. do a task on a hourly/daily/weekly base. You'd create the thread (and keep a handle to it) in either an InitServlet.init() and then Thread.interrupt() in the InitServlet.destroy(), or you can do it in an ApplicationListener (something like that) class which I think you can define in the web.xml. How else can you implement that (monitoring) in Tomcat? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - 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: [Q] Is it safe to create threads in Tomcat web-apps? (JCrontab)
This looks promising, but what do they do differently than just starting a deamon thread and doing some background work? Why bother with this if you can start your own custom thread, or do they do something else? --- Kwok Peng Tuck [EMAIL PROTECTED] wrote: Hello Riaan, you might want to check out jcrontab. http://jcrontab.sourceforge.net Riaan Oberholzer wrote: Well, that was part of my question if I cannot/don't implement daemon threads to do e.g. automatic daily tasks, what else? E.g, at the end of the day send an e-mail to a (real life) manager with a summary of the day's transactions something like that. Does Tomcat provide some sort of ActionEvent which you can configure to be fired every x milliseconds? --- Tim Funk [EMAIL PROTECTED] wrote: You can create threads all day in tomcat, but here are the importnatn things to consider: - WHY! Are threads really the correct solution? - If you create threads - what are their scope? Daemon, non-daemon? - If you create non-daemon threads - be prepared for the consequences such as the JVM not going away on tomcat shutdown unless you have taken the needed precautions. - If you create dameon only threads, be prepared for when tomcat shuts down and your daemon still has work to do because the JVM could exit before your thread is ready to complete its unit of work - WHY! Are threads really the correct solution? - And last but not least: WHY! Are threads really the correct solution? -Tim Riaan Oberholzer wrote: I've mainly worked in BEA WebLogic before and from colleagues and other sources I have heard it is not recommended (and sometimes not allowed, some even said) to create threads in your application. Indeed, when the application went live in a multi-server clustered environment, we got very inconsistent results because of the threads, so we had to remove them. Question is, how safe is it to create threads in a Tomcat web-app? I would assume worker threads are ok, i.e. threads you create to do a specific task and then it terminates. When you are guaranteed the thread will terminate either because of an error or because the assigned task has been completed. But what about monitor threads, i.e. threads that does a Thread.sleep(x) for an hour, check some condition and goes back to sleep... some mechanism you implement to e.g. do a task on a hourly/daily/weekly base. You'd create the thread (and keep a handle to it) in either an InitServlet.init() and then Thread.interrupt() in the InitServlet.destroy(), or you can do it in an ApplicationListener (something like that) class which I think you can define in the web.xml. How else can you implement that (monitoring) in Tomcat? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - 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] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Q] Is it safe to create threads in Tomcat web-apps?
Tomcat doesn't provide this but other simple solutions exist such as exposing a URL and using cron + wget. (Some may also say kludge too) As for aggregating statistics - I would recommend using a log file to record the essential measurements then running your stats program on the logs. This way - tomcat can crash (or other strange occurences may occur) and you lose no data. If the data is already logged, then the first solution (cron + wget) will work well too. -Tim Riaan Oberholzer wrote: Well, that was part of my question if I cannot/don't implement daemon threads to do e.g. automatic daily tasks, what else? E.g, at the end of the day send an e-mail to a (real life) manager with a summary of the day's transactions something like that. Does Tomcat provide some sort of ActionEvent which you can configure to be fired every x milliseconds? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Q] Is it safe to create threads in Tomcat web-apps?
... nice suggestion, but I am delivering an application as a .war file to a 3rd party and they just want the .war (+ context.xml) with everything in it hence, no other applications checking the logs or database. All functionality must come from the .war running in Tomcat. It is very important: all functionality must be encapsulated in the .war file. (I have no idea what cron +wegt is???) I guess a daemon thread will be my choice solution for now... what the thread does, is check a database daily for a certain false condition and send an e-mail to all users in question warning them about the current status. E.g. if you have to submit your timesheet by Friday 17:00, then you'll get a warning on Friday at 12:00 if it is not done yet something like that. --- Tim Funk [EMAIL PROTECTED] wrote: Tomcat doesn't provide this but other simple solutions exist such as exposing a URL and using cron + wget. (Some may also say kludge too) As for aggregating statistics - I would recommend using a log file to record the essential measurements then running your stats program on the logs. This way - tomcat can crash (or other strange occurences may occur) and you lose no data. If the data is already logged, then the first solution (cron + wget) will work well too. -Tim Riaan Oberholzer wrote: Well, that was part of my question if I cannot/don't implement daemon threads to do e.g. automatic daily tasks, what else? E.g, at the end of the day send an e-mail to a (real life) manager with a summary of the day's transactions something like that. Does Tomcat provide some sort of ActionEvent which you can configure to be fired every x milliseconds? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Q] Is it safe to create threads in Tomcat web-apps?
cron = scheduler wget = command line HTTP/HTTPS client The requirement for delivering everything in a WAR file is all nice and dandy, but if you think about it, the requirement automatically breaks the other requirement: scheduling. If you cannot have a log file, and you cannot access a database, how will you ever be able to determine elapsed time, which is the primary requirement for a scheduler? How can you determine status like when was the last time it was run, etc? How can you reset your clock if the app is shutdown? How do you know the app has been shutdown due to an external event? John Riaan Oberholzer wrote: ... nice suggestion, but I am delivering an application as a .war file to a 3rd party and they just want the .war (+ context.xml) with everything in it hence, no other applications checking the logs or database. All functionality must come from the .war running in Tomcat. It is very important: all functionality must be encapsulated in the .war file. (I have no idea what cron +wegt is???) I guess a daemon thread will be my choice solution for now... what the thread does, is check a database daily for a certain false condition and send an e-mail to all users in question warning them about the current status. E.g. if you have to submit your timesheet by Friday 17:00, then you'll get a warning on Friday at 12:00 if it is not done yet something like that. --- Tim Funk [EMAIL PROTECTED] wrote: Tomcat doesn't provide this but other simple solutions exist such as exposing a URL and using cron + wget. (Some may also say kludge too) As for aggregating statistics - I would recommend using a log file to record the essential measurements then running your stats program on the logs. This way - tomcat can crash (or other strange occurences may occur) and you lose no data. If the data is already logged, then the first solution (cron + wget) will work well too. -Tim Riaan Oberholzer wrote: Well, that was part of my question if I cannot/don't implement daemon threads to do e.g. automatic daily tasks, what else? E.g, at the end of the day send an e-mail to a (real life) manager with a summary of the day's transactions something like that. Does Tomcat provide some sort of ActionEvent which you can configure to be fired every x milliseconds? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - 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: [Q] Is it safe to create threads in Tomcat web-apps?
Perhaps I should give a better explanation of how the application works: I deliver a .war file. I do have access to an underlying database. The scheduled tasks perform more on a is time reached than has time elapsed principle... eg, it triggers when is it past midnight? instead of has 24 hours elapsed?. I cannot see why creating a daemon thread cannot cater for this. You just start the thread in the init method of the InitServlet (or any servlet you create with start-when-app-starts). What am I missing here? Why can't I use this method? If Tomcat crashes and the app gets restarted, my thread will be restarted as well, so no problem there. The thread should also only be running while the web-app is (LONG story why that is so, so I won't give details... in short, if the web-app is down, it is seen as critical and all else must be halted). --- John Turner [EMAIL PROTECTED] wrote: cron = scheduler wget = command line HTTP/HTTPS client The requirement for delivering everything in a WAR file is all nice and dandy, but if you think about it, the requirement automatically breaks the other requirement: scheduling. If you cannot have a log file, and you cannot access a database, how will you ever be able to determine elapsed time, which is the primary requirement for a scheduler? How can you determine status like when was the last time it was run, etc? How can you reset your clock if the app is shutdown? How do you know the app has been shutdown due to an external event? John Riaan Oberholzer wrote: ... nice suggestion, but I am delivering an application as a .war file to a 3rd party and they just want the .war (+ context.xml) with everything in it hence, no other applications checking the logs or database. All functionality must come from the .war running in Tomcat. It is very important: all functionality must be encapsulated in the .war file. (I have no idea what cron +wegt is???) I guess a daemon thread will be my choice solution for now... what the thread does, is check a database daily for a certain false condition and send an e-mail to all users in question warning them about the current status. E.g. if you have to submit your timesheet by Friday 17:00, then you'll get a warning on Friday at 12:00 if it is not done yet something like that. --- Tim Funk [EMAIL PROTECTED] wrote: Tomcat doesn't provide this but other simple solutions exist such as exposing a URL and using cron + wget. (Some may also say kludge too) As for aggregating statistics - I would recommend using a log file to record the essential measurements then running your stats program on the logs. This way - tomcat can crash (or other strange occurences may occur) and you lose no data. If the data is already logged, then the first solution (cron + wget) will work well too. -Tim Riaan Oberholzer wrote: Well, that was part of my question if I cannot/don't implement daemon threads to do e.g. automatic daily tasks, what else? E.g, at the end of the day send an e-mail to a (real life) manager with a summary of the day's transactions something like that. Does Tomcat provide some sort of ActionEvent which you can configure to be fired every x milliseconds? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - 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] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Q] Is it safe to create threads in Tomcat web-apps?
Nobody, from what I can tell, is saying can't. You did ask, though. If you're willing to be diligent about coding your threads, go for it. I think the point of previous posts was that in many cases, there is no need for such a thing as your asking. There are always exceptions to the rule, though. For example: the question is it past midnight would never be asked if you were to use the operating system, since with something like cron (built in scheduler), the operating already knows if its past midnight. Thus, the question becomes not a question but a command: its past midnight, go find all of the people who have a status of X and remind them to change their status to Y. The effort, then, is spent on the business logic, not on trying to figure out if its time to spend time on the business logic. The alternative is to spend resources constantly wondering if a specific time is reached. For one or two events, no problem. Start getting busy, start having 10 or 20 events, and it becomes a problem, not just from a resource standpoint, but from an administration and synchronization standpoint. John Riaan Oberholzer wrote: Perhaps I should give a better explanation of how the application works: I deliver a .war file. I do have access to an underlying database. The scheduled tasks perform more on a is time reached than has time elapsed principle... eg, it triggers when is it past midnight? instead of has 24 hours elapsed?. I cannot see why creating a daemon thread cannot cater for this. You just start the thread in the init method of the InitServlet (or any servlet you create with start-when-app-starts). What am I missing here? Why can't I use this method? If Tomcat crashes and the app gets restarted, my thread will be restarted as well, so no problem there. The thread should also only be running while the web-app is (LONG story why that is so, so I won't give details... in short, if the web-app is down, it is seen as critical and all else must be halted). --- John Turner [EMAIL PROTECTED] wrote: cron = scheduler wget = command line HTTP/HTTPS client The requirement for delivering everything in a WAR file is all nice and dandy, but if you think about it, the requirement automatically breaks the other requirement: scheduling. If you cannot have a log file, and you cannot access a database, how will you ever be able to determine elapsed time, which is the primary requirement for a scheduler? How can you determine status like when was the last time it was run, etc? How can you reset your clock if the app is shutdown? How do you know the app has been shutdown due to an external event? John Riaan Oberholzer wrote: ... nice suggestion, but I am delivering an application as a .war file to a 3rd party and they just want the .war (+ context.xml) with everything in it hence, no other applications checking the logs or database. All functionality must come from the .war running in Tomcat. It is very important: all functionality must be encapsulated in the .war file. (I have no idea what cron +wegt is???) I guess a daemon thread will be my choice solution for now... what the thread does, is check a database daily for a certain false condition and send an e-mail to all users in question warning them about the current status. E.g. if you have to submit your timesheet by Friday 17:00, then you'll get a warning on Friday at 12:00 if it is not done yet something like that. --- Tim Funk [EMAIL PROTECTED] wrote: Tomcat doesn't provide this but other simple solutions exist such as exposing a URL and using cron + wget. (Some may also say kludge too) As for aggregating statistics - I would recommend using a log file to record the essential measurements then running your stats program on the logs. This way - tomcat can crash (or other strange occurences may occur) and you lose no data. If the data is already logged, then the first solution (cron + wget) will work well too. -Tim Riaan Oberholzer wrote: Well, that was part of my question if I cannot/don't implement daemon threads to do e.g. automatic daily tasks, what else? E.g, at the end of the day send an e-mail to a (real life) manager with a summary of the day's transactions something like that. Does Tomcat provide some sort of ActionEvent which you can configure to be fired every x milliseconds? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: [Q] Is it safe to create threads in Tomcat web-apps?
You're right, no-one said I can't. :) I was hoping someone who has actually used it could give some feedback about it. The (obvious) reason why the scheduled task also cannot be active if the web-app is not active, is that the scheduled task requires users to use web-app. Eg, Friday at 15:00 you get an e-mail to fill in your time-sheet if it has not been done. If the web-app is not active, then there is no point in sending the mail. If you do, then the sysop is going to get 1000 mails/phone call from users saying I need to fill out my timesheet, but the app is down!. Purely a user requirement. I think you can see the logic behind this. When the web-app comes alive again, the first thing that will be done, is to send the warnings and people can get back to filling out timesheets. It won't be a heavy burderned task... thread.sleep for 1 hour eg and then do one date/time check I think that wouldn't be too heavy on performance. Thanks for the feedback, though. --- John Turner [EMAIL PROTECTED] wrote: Nobody, from what I can tell, is saying can't. You did ask, though. If you're willing to be diligent about coding your threads, go for it. I think the point of previous posts was that in many cases, there is no need for such a thing as your asking. There are always exceptions to the rule, though. For example: the question is it past midnight would never be asked if you were to use the operating system, since with something like cron (built in scheduler), the operating already knows if its past midnight. Thus, the question becomes not a question but a command: its past midnight, go find all of the people who have a status of X and remind them to change their status to Y. The effort, then, is spent on the business logic, not on trying to figure out if its time to spend time on the business logic. The alternative is to spend resources constantly wondering if a specific time is reached. For one or two events, no problem. Start getting busy, start having 10 or 20 events, and it becomes a problem, not just from a resource standpoint, but from an administration and synchronization standpoint. John Riaan Oberholzer wrote: Perhaps I should give a better explanation of how the application works: I deliver a .war file. I do have access to an underlying database. The scheduled tasks perform more on a is time reached than has time elapsed principle... eg, it triggers when is it past midnight? instead of has 24 hours elapsed?. I cannot see why creating a daemon thread cannot cater for this. You just start the thread in the init method of the InitServlet (or any servlet you create with start-when-app-starts). What am I missing here? Why can't I use this method? If Tomcat crashes and the app gets restarted, my thread will be restarted as well, so no problem there. The thread should also only be running while the web-app is (LONG story why that is so, so I won't give details... in short, if the web-app is down, it is seen as critical and all else must be halted). --- John Turner [EMAIL PROTECTED] wrote: cron = scheduler wget = command line HTTP/HTTPS client The requirement for delivering everything in a WAR file is all nice and dandy, but if you think about it, the requirement automatically breaks the other requirement: scheduling. If you cannot have a log file, and you cannot access a database, how will you ever be able to determine elapsed time, which is the primary requirement for a scheduler? How can you determine status like when was the last time it was run, etc? How can you reset your clock if the app is shutdown? How do you know the app has been shutdown due to an external event? John Riaan Oberholzer wrote: ... nice suggestion, but I am delivering an application as a .war file to a 3rd party and they just want the .war (+ context.xml) with everything in it hence, no other applications checking the logs or database. All functionality must come from the .war running in Tomcat. It is very important: all functionality must be encapsulated in the .war file. (I have no idea what cron +wegt is???) I guess a daemon thread will be my choice solution for now... what the thread does, is check a database daily for a certain false condition and send an e-mail to all users in question warning them about the current status. E.g. if you have to submit your timesheet by Friday 17:00, then you'll get a warning on Friday at 12:00 if it is not done yet something like that. --- Tim Funk [EMAIL PROTECTED] wrote: Tomcat doesn't provide this but other simple solutions exist such as exposing a URL and using cron + wget. (Some may also say kludge too) As for aggregating statistics - I would recommend using a log file to record the essential measurements
RE: [Q] Is it safe to create threads in Tomcat web-apps?
Howdy, I cannot see why creating a daemon thread cannot cater for this. You just start the thread in the init method of the InitServlet (or any servlet you create with start-when-app-starts). I'm actually a fan of the background daemon-thread approach, and think the user-threading limitations in full J2EE containers is unfortunate (although I know where it comes from). Be careful about starting and stopping threads in the init/destroy methods of servlets, however, as the container can create/destroy your servlets (including load-on-startup servlets) almost whenever it wants to. Consider using a context listener instead. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Q] Is it safe to create threads in Tomcat web-apps?
Yep, thanks... I've heard from other sources as well that the ServletContextListener approach is better. It gives me some comfort knowing other people find the approach safe and without too many pitfalls. :) --- Shapira, Yoav [EMAIL PROTECTED] wrote: Howdy, I cannot see why creating a daemon thread cannot cater for this. You just start the thread in the init method of the InitServlet (or any servlet you create with start-when-app-starts). I'm actually a fan of the background daemon-thread approach, and think the user-threading limitations in full J2EE containers is unfortunate (although I know where it comes from). Be careful about starting and stopping threads in the init/destroy methods of servlets, however, as the container can create/destroy your servlets (including load-on-startup servlets) almost whenever it wants to. Consider using a context listener instead. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Q] Is it safe to create threads in Tomcat web-apps?
From: Tim Funk funkman () joedog ! org Subject: Re: [Q] Is it safe to create threads in Tomcat web-apps? You can create threads all day in tomcat, but here are the importnatn things to consider: - WHY! Are threads really the correct solution? - And last but not least: WHY! Are threads really the correct solution? I'm getting the impression that you think multiple threads are never the right answer. :) That's not necessarily true. Suppose that your response to a request contains three steps which are independant of one another; in order to deliver a faster response time, you'd like to execute them concurrently. If these three steps are CPU-bound, then the amount of benefit really depends on the machine; you need multiple CPUs so that the scheduler can run the different threads on different CPUs. With a single CPU, you're not likely to see much benefit. However, if the three steps are IO-bound, using multiple threads to run them concurrently can lead to a big improvement. Most of the time spent doing IO is spent waiting. (Particularly if the IO is network IO, a sub-request to a remote site, for example). If the idle times occur concurrently instead of serially, you'll certainly do better. -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Q] Is it safe to create threads in Tomcat web-apps?
I am in total agreement and I have used user created threads on my site. I view user created threads as a dangerous and usually un-needed thing. Dangerous because of the side effects that aren't accounted for by more junior programmers such as concurrency, shutting down the JVM (or lack of being able to), more threads the system may handle, harder to track from a monitoring point of view the activites occuring in the JVM for trouble shooting. User threads are not always a bad thing. But they can easily be abused because they seem like a cool-fun-novel coding solution. -Tim [EMAIL PROTECTED] wrote: From: Tim Funk funkman () joedog ! org - WHY! Are threads really the correct solution? - And last but not least: WHY! Are threads really the correct solution? I'm getting the impression that you think multiple threads are never the right answer. :) That's not necessarily true. Suppose that your response to a request contains three steps which are independant of one another; in order to deliver a faster response time, you'd like to execute them concurrently. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Q] Is it safe to create threads in Tomcat web-apps?
I hate to speak for someone else, but I believe that Tim may have been referring to the tendency of some people to use threads without understanding their limitations. (I've seen attempts to massively thread CPU-bound applications on single CPU machines.) Threads are not magic that can be spread on a program to make it better. That being said. Tim did not say don't he asked why.grin/ That's much politer than I've normally been to people in a similar circumstance. shrug/ G. Wade [EMAIL PROTECTED] wrote: From: Tim Funk funkman () joedog ! org Subject: Re: [Q] Is it safe to create threads in Tomcat web-apps? You can create threads all day in tomcat, but here are the importnatn things to consider: - WHY! Are threads really the correct solution? - And last but not least: WHY! Are threads really the correct solution? I'm getting the impression that you think multiple threads are never the right answer. :) That's not necessarily true. Suppose that your response to a request contains three steps which are independant of one another; in order to deliver a faster response time, you'd like to execute them concurrently. If these three steps are CPU-bound, then the amount of benefit really depends on the machine; you need multiple CPUs so that the scheduler can run the different threads on different CPUs. With a single CPU, you're not likely to see much benefit. However, if the three steps are IO-bound, using multiple threads to run them concurrently can lead to a big improvement. Most of the time spent doing IO is spent waiting. (Particularly if the IO is network IO, a sub-request to a remote site, for example). If the idle times occur concurrently instead of serially, you'll certainly do better. -- Steve - 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]
How to increase max threads in Tomcat 4.1.12?
Hi, When we ran a stress test on our application, it hang Tomcat service. We found an INFO message in stderr a message below INFO: All threads are busy, waiting. Please increase maxThreads or check the servlet status200 200 I have tried to increase the maxProcessors in \conf\server.xml from 200 to 500 and 500 to 1000, but that didn't help. We ran a stress test with 200 concurrent users. Here's our sample setting for 500 max processor Connector className=org.apache.coyote.tomcat4.CoyoteConnector acceptCount=10 bufferSize=2048 connectionTimeout=2 debug=0 enableLookups=true maxProcessors=500 minProcessors=5 port=8080 protocolHandlerClassName=org.apache.coyote.http11.Http11Protocol proxyPort=0 redirectPort=8443 scheme=https secure=true tcpNoDelay=true useURIValidationHack=false Factory className=org.apache.catalina.net.DefaultServerSocketFactory/ /Connector Connector className=org.apache.coyote.tomcat4.CoyoteConnector acceptCount=10 bufferSize=2048 connectionTimeout=2 debug=0 enableLookups=true maxProcessors=500 minProcessors=5 port=8009 protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler proxyPort=0 redirectPort=8443 scheme=https secure=true tcpNoDelay=true useURIValidationHack=false Factory className=org.apache.catalina.net.DefaultServerSocketFactory/ /Connector How do we solve/increase the maxThreads issue? Thanks, Tuan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Apache threads and tomcat connections
Will apache create on connection to tomcat for each child server, or for each thread? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Starting threads on tomcat startup
I have a number of threads that I would like to launch when tomcat loads. until recently I was just using the first request to launch them but I would prefer that they just started automatically when tomcat starts. Is there any way to start new threads when tomcat is launched? Thanks Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Starting threads on tomcat startup
Use a servlet's init() method and have it load at startup. search google: tomcat web.xml load-on-startup fillup On 5/30/02 1:05 AM, rob [EMAIL PROTECTED] wrote: I have a number of threads that I would like to launch when tomcat loads. until recently I was just using the first request to launch them but I would prefer that they just started automatically when tomcat starts. Is there any way to start new threads when tomcat is launched? Thanks Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tracking Threads inside Tomcat
I hope that someone will be able to help. I have tomcat 3.2 running on a Sun Solaris platform and on my Mac OS-X. But after 5 to 10 hours Tomcat reaches some kind of deadlock on the Sun. Now I know that this is NOT a Tomcat issue, it is my code. But due to the length of time it takes to get to this stage it is very hard to debug. But I believe that it is a problem related to Threads not completing; for some reason. is there any way that I can trace the Threads, check their Stack Trace or something? I only have access remotely via a terminal window. Thank you. I v a n ... Ivan Markovic SculptLight http://www.sculptlight.com (+353) 87 2939256 (+353) 1 2982205 114 Lower Churchtown Rd, Dublin 14, Ireland. --
RE: Tracking Threads inside Tomcat
Depending on your JVM, you may be able to do a break (Ctrl+Break on Windows, Ctrl+Y on several Unixes) in the window running Tomcat (or any Java application) to get a stack trace. Dunno how (or even if) it can be done on Macs. Failing that, you could use jdb to connect to the Tomcat process, enter stop, then where all to get a stack dump. -- Bill K. -Original Message- From: Ivan E. Markovic [mailto:[EMAIL PROTECTED]] Sent: Monday, July 23, 2001 4:28 AM To: [EMAIL PROTECTED] Subject: Tracking Threads inside Tomcat Importance: High I hope that someone will be able to help. I have tomcat 3.2 running on a Sun Solaris platform and on my Mac OS-X. But after 5 to 10 hours Tomcat reaches some kind of deadlock on the Sun. Now I know that this is NOT a Tomcat issue, it is my code. But due to the length of time it takes to get to this stage it is very hard to debug. But I believe that it is a problem related to Threads not completing; for some reason. is there any way that I can trace the Threads, check their Stack Trace or something? I only have access remotely via a terminal window. Thank you. I v a n ... Ivan Markovic SculptLight http://www.sculptlight.com (+353) 87 2939256 (+353) 1 2982205 114 Lower Churchtown Rd, Dublin 14, Ireland. --
Threads in TOMCAT 3.2
Hi, Anybody knows if it's posible encrease the number of threads with TOMCAT 3.2. I'm doing some performance testing and when I try to execute more that 100 request simultaneously I get the the error ... 2001-06-27 03:01:18 - ThreadPool: Pool exhausted with 100 threads. It's posible define the ThreadPool varible? Where is it? Thanks in advance and best regards, Jose
