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
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.
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]
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
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
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
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
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
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
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]
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."
