RE: Threaded servlets okay in a compliant container?
Howdy, One thing to note is that a servlet container and a J2EE server are not the same. Tomcat is the former but not the latter. Weblogic, websphere, jboss, etc. are the latter. They implement the whole J2EE spec which places more restrictions on thread creation by applications: read the spec if you want the actual text (I don't remember if off-hand). In a servlet containr, you can create your own threads. Just like in other environments, you must be careful with how you manage them, especially making sure they are appropriately terminated by your application or by the JVM itself if they're daemons. Yoav Shapira Millennium ChemInformatics >-Original Message- >From: David Wall [mailto:[EMAIL PROTECTED] >Sent: Tuesday, December 30, 2003 12:15 PM >To: [EMAIL PROTECTED] >Subject: Threaded servlets okay in a compliant container? > >I recall reading that conformant servlets and such (EJBs?) do not create >their own threads, something about being a container issue. > >Does anybody know the primary objection to launching threads that take >on a life of their own? The container doesn't really need to manage it, >per >se. >I suppose a container can drop servlet objects from memory, but as that >wouldn't necessarily affect a daemon thread, it seems that doesn't harm > launching them at startup, and of course the servlet could even stop the >threads when told to destroy itself if that makes sense. > >Does anybody know if most servlet containers today (Tomcat 4+, WebLogic, >WebSphere...) have a real problem with such new threads being created or >not? What would be the risk in my using them? > >I previously posted this by accident on the PostgreSQL JDBC list and I got >mixed answers. Some say it's fine, others say there's no spec saying such >threads can't be used, and others say that BEA complained about support >issues related to apps that created their own threads. > >Any feedback is much appreciated. > >Thanks, >David > > >- >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: Threaded servlets okay in a compliant container?
Also ... (From 2.3 spec) In SRV.1.2 What is a Servlet Container? ... "For example, high-end application servers may limit the creation of a Thread object, to insure that other components of the container are not negatively impacted." SRV.9.11 Web Application Environment ... "Such servlet containers should support this behavior when performed on threads created by the developer, but are not currently required to do so. Such a requirement will be added in the next version of this specification. Developers are cautioned that depending on this capability for application-created threads is nonportable." -Tim Shapira, Yoav wrote: Howdy, One thing to note is that a servlet container and a J2EE server are not the same. Tomcat is the former but not the latter. Weblogic, websphere, jboss, etc. are the latter. They implement the whole J2EE spec which places more restrictions on thread creation by applications: read the spec if you want the actual text (I don't remember if off-hand). In a servlet containr, you can create your own threads. Just like in other environments, you must be careful with how you manage them, especially making sure they are appropriately terminated by your application or by the JVM itself if they're daemons. Yoav Shapira Millennium ChemInformatics -Original Message- From: David Wall [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 30, 2003 12:15 PM To: [EMAIL PROTECTED] Subject: Threaded servlets okay in a compliant container? I recall reading that conformant servlets and such (EJBs?) do not create their own threads, something about being a container issue. Does anybody know the primary objection to launching threads that take on a life of their own? The container doesn't really need to manage it, per se. I suppose a container can drop servlet objects from memory, but as that wouldn't necessarily affect a daemon thread, it seems that doesn't harm launching them at startup, and of course the servlet could even stop the threads when told to destroy itself if that makes sense. Does anybody know if most servlet containers today (Tomcat 4+, WebLogic, WebSphere...) have a real problem with such new threads being created or not? What would be the risk in my using them? I previously posted this by accident on the PostgreSQL JDBC list and I got mixed answers. Some say it's fine, others say there's no spec saying such threads can't be used, and others say that BEA complained about support issues related to apps that created their own threads. Any feedback is much appreciated. Thanks, David - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Threaded servlets okay in a compliant container?
SRV.9.11 says the same thing in the 2.4 spec so it's still not defined as of Tomcat 5 either. --- Tim Funk <[EMAIL PROTECTED]> wrote: > Also ... (From 2.3 spec) > > In SRV.1.2 What is a Servlet Container? > ... "For example, high-end application servers may limit the creation > of a > Thread object, to insure that other components of the container are > not > negatively impacted." > > SRV.9.11 Web Application Environment > ... "Such servlet containers should support this behavior when > performed on > threads created by the developer, but are not currently required to > do so. > Such a requirement will be added in the next version of this > specification. > Developers are cautioned that depending on this capability for > application-created threads is nonportable." > > -Tim > > Shapira, Yoav wrote: > > > Howdy, > > One thing to note is that a servlet container and a J2EE server are > not > > the same. Tomcat is the former but not the latter. Weblogic, > > websphere, jboss, etc. are the latter. They implement the whole > J2EE > > spec which places more restrictions on thread creation by > applications: > > read the spec if you want the actual text (I don't remember if > > off-hand). > > > > In a servlet containr, you can create your own threads. Just like > in > > other environments, you must be careful with how you manage them, > > especially making sure they are appropriately terminated by your > > application or by the JVM itself if they're daemons. > > > > Yoav Shapira > > Millennium ChemInformatics > > > > > > > >>-Original Message- > >>From: David Wall [mailto:[EMAIL PROTECTED] > >>Sent: Tuesday, December 30, 2003 12:15 PM > >>To: [EMAIL PROTECTED] > >>Subject: Threaded servlets okay in a compliant container? > >> > >>I recall reading that conformant servlets and such (EJBs?) do not > > > > create > > > >>their own threads, something about being a container issue. > >> > >>Does anybody know the primary objection to launching threads that > take > >>on a life of their own? The container doesn't really need to > manage > > > > it, > > > >>per > >>se. > >>I suppose a container can drop servlet objects from memory, but as > that > >>wouldn't necessarily affect a daemon thread, it seems that doesn't > harm > >>launching them at startup, and of course the servlet could even > stop > > > > the > > > >>threads when told to destroy itself if that makes sense. > >> > >>Does anybody know if most servlet containers today (Tomcat 4+, > > > > WebLogic, > > > >>WebSphere...) have a real problem with such new threads being > created > > > > or > > > >>not? What would be the risk in my using them? > >> > >>I previously posted this by accident on the PostgreSQL JDBC list > and I > > > > got > > > >>mixed answers. Some say it's fine, others say there's no spec > saying > > > > such > > > >>threads can't be used, and others say that BEA complained about > support > >>issues related to apps that created their own threads. > >> > >>Any feedback is much appreciated. > >> > >>Thanks, > >>David > >> > >> > >>- > >>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] > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Threaded servlets okay in a compliant container?
Just found this while searching for something else... http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&q=J2CA007 5W&uid=swg21109248&loc=en_US&cs=utf-8&lang=en+en It doesn't look related at first, but keep reading the 'Cause' section. Does anyone know what's the 'real' story regarding threads in servlet containers. It seems that what IBM is saying is that "they are supported within a transactional context", but I can't find this in the newest spec. Did I miss it? (or is it in a broader J2EE spec somewhere?) > -Original Message- > From: David Ramsey [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 30, 2003 1:10 PM > To: Tomcat Users List > Subject: Re: Threaded servlets okay in a compliant container? > > > SRV.9.11 says the same thing in the 2.4 spec so it's still > not defined as of Tomcat 5 either. > > > --- Tim Funk <[EMAIL PROTECTED]> wrote: > > Also ... (From 2.3 spec) > > > > In SRV.1.2 What is a Servlet Container? > > ... "For example, high-end application servers may limit > the creation > > of a Thread object, to insure that other components of the > container > > are not > > negatively impacted." > > > > SRV.9.11 Web Application Environment > > ... "Such servlet containers should support this behavior when > > performed on threads created by the developer, but are not > currently > > required to do so. > > Such a requirement will be added in the next version of this > > specification. > > Developers are cautioned that depending on this capability for > > application-created threads is nonportable." > > > > -Tim > > > > Shapira, Yoav wrote: > > > > > Howdy, > > > One thing to note is that a servlet container and a J2EE > server are > > not > > > the same. Tomcat is the former but not the latter. Weblogic, > > > websphere, jboss, etc. are the latter. They implement the whole > > J2EE > > > spec which places more restrictions on thread creation by > > applications: > > > read the spec if you want the actual text (I don't remember if > > > off-hand). > > > > > > In a servlet containr, you can create your own threads. Just like > > in > > > other environments, you must be careful with how you manage them, > > > especially making sure they are appropriately terminated by your > > > application or by the JVM itself if they're daemons. > > > > > > Yoav Shapira > > > Millennium ChemInformatics > > > > > > > > > > > >>-Original Message- > > >>From: David Wall [mailto:[EMAIL PROTECTED] > > >>Sent: Tuesday, December 30, 2003 12:15 PM > > >>To: [EMAIL PROTECTED] > > >>Subject: Threaded servlets okay in a compliant container? > > >> > > >>I recall reading that conformant servlets and such (EJBs?) do not > > > > > > create > > > > > >>their own threads, something about being a container issue. > > >> > > >>Does anybody know the primary objection to launching threads that > > take > > >>on a life of their own? The container doesn't really need to > > manage > > > > > > it, > > > > > >>per > > >>se. > > >>I suppose a container can drop servlet objects from memory, but as > > that > > >>wouldn't necessarily affect a daemon thread, it seems that doesn't > > harm > > >>launching them at startup, and of course the servlet could even > > stop > > > > > > the > > > > > >>threads when told to destroy itself if that makes sense. > > >> > > >>Does anybody know if most servlet containers today (Tomcat 4+, > > > > > > WebLogic, > > > > > >>WebSphere...) have a real problem with such new threads being > > created > > > > > > or > > > > > >>not? What would be the risk in my using them? > > >> > > >>I previously posted this by accident on the PostgreSQL JDBC list > > and I > > > > > > got > > > > > >>mixed answers. Some say it's fine, others say there's no spec > > saying > > > > > > such > > > > > >>threads can't be used, and others say that BEA complained about > > support > > >>issues related t
Re: Threaded servlets okay in a compliant container?
If we use our own connection pools and handle our own transactions within the db, is there likely any issue with using other threads to do background tasks that touch the database? I can see there may be issues in a regular EJB world with declarative transactions and such (does EJB have its own "self-thread" type of object that can do background tasks without waiting for a new transaction event to arrive?), but maybe these are not a real issue with simpler servlets only. I've found so many of these "annoying" artifacts that it makes one wonder if anybody had actually tried to create a complete, non-trivial application using the technology that was standardized. For example, nearly every data input field (INPUT, TEXTAREA) and all output data for a JSP/servlet requires that you escape the data being displayed (or default VALUE aspects for INPUT fields) since it may contain double quotes or other things that would muck up the HTML if not escaped, so every field needs to be escaped for display. Background threads are not necessarily compliant, but how would anybody effect simple policies like "lock out a user's login for 5 minutes after repeated failures," or deleting old data in logs, or doing any task every 5 minutes, every day, once a week, etc.? It seems that everybody who writes a JSP/servlet application also has to write standalone Java apps to do these things, which just complicates matters (another process has to be running that's not part of the servlet environment so it has to start/stop with it, another application has to access the database using yet another connection pool, two JVMs means splitting available memory across multiple JVMs instead of just configuring the max in one, threads can wake each other up for event processing, but this requires RMI or another mechanism between two JVMs, etc.) David Mike Curwen wrote: Just found this while searching for something else... http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&q=J2CA007 5W&uid=swg21109248&loc=en_US&cs=utf-8&lang=en+en It doesn't look related at first, but keep reading the 'Cause' section. Does anyone know what's the 'real' story regarding threads in servlet containers. It seems that what IBM is saying is that "they are supported within a transactional context", but I can't find this in the newest spec. Did I miss it? (or is it in a broader J2EE spec somewhere?) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Threaded servlets okay in a compliant container?
- Nobody (the spec included) prevents you from creating threads You just have to follow some rules. - Besides creating threads I prefer to use servlets/jsp's that are triggered from the outside to do regular jobs. (Using cron and wget to trigger the action) This way you don't have to deal with threads and the job runs inside the servlet environment. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 31, 2003 1:46 AM > To: Tomcat Users List > Subject: Re: Threaded servlets okay in a compliant container? > > > If we use our own connection pools and handle our own transactions > within the db, is there likely any issue with using other > threads to do > background tasks that touch the database? I can see there > may be issues > in a regular EJB world with declarative transactions and such > (does EJB > have its own "self-thread" type of object that can do > background tasks > without waiting for a new transaction event to arrive?), but > maybe these > are not a real issue with simpler servlets only. > > Background threads are not necessarily compliant, but how would > anybody effect simple policies like > "lock out a user's login for 5 minutes after repeated failures," or > deleting old data in logs, or doing any task every 5 minutes, > every day, > once a week, etc.? It seems that everybody who writes a JSP/servlet > application also has to write standalone Java apps to do > these things, > which just complicates matters (another process has to be > running that's > not part of the servlet environment so it has to start/stop with it, > another application has to access the database using yet another > connection pool, two JVMs means splitting available memory across > multiple JVMs instead of just configuring the max in one, threads can > wake each other up for event processing, but this requires RMI or > another mechanism between two JVMs, etc.) > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Threaded servlets okay in a compliant container?
Ralph Einfeldt wrote: - Nobody (the spec included) prevents you from creating threads You just have to follow some rules. Yes, but it should make you think twice before indulging in something like that. It also might prevent re-inventing the wheel. - Besides creating threads I prefer to use servlets/jsp's that are triggered from the outside to do regular jobs. (Using cron and wget to trigger the action) This way you don't have to deal with threads and the job runs inside the servlet environment. Why would a cron triggered job benefit from Servlet container environment? Servlets are mainly for HTTP client/server interaction. Cron jobs are for no interaction. I could imagine (and approve) a cron job firing JMS message to be caught by a Message EJB, but a Servlet...? Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Threaded servlets okay in a compliant container?
The cronjob is requesting an url with wget and triggers tis way a servlet. That's easy and sufficient to do regular jobs like sending newsletters, cleaning up files, that don't require any interaction) > -Original Message- > From: Nikola Milutinovic [mailto:[EMAIL PROTECTED] > Sent: Monday, January 05, 2004 11:56 AM > To: Tomcat Users List > Subject: Re: Threaded servlets okay in a compliant container? > > Why would a cron triggered job benefit from Servlet container > environment? > Servlets are mainly for HTTP client/server interaction. Cron > jobs are for no interaction. > > I could imagine (and approve) a cron job firing JMS message > to be caught by a > Message EJB, but a Servlet...? > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Threaded servlets okay in a compliant container?
Ralph Einfeldt wrote: The cronjob is requesting an url with wget and triggers tis way a servlet. I understood the mechanism being used, I did not understand the benefit. That's easy and sufficient to do regular jobs like sending newsletters, cleaning up files, that don't require any interaction) Why is it easier to do those things from a Servlet, than a regular shell script? If you want to trigger those actions remotely, I'd advise you to look at Secure SHell products, like OpenSSH. How did you provide authentication and security for those Servlet triggered jobs? HTTP user/pass? HTTPS user/pass? With SSH you're as safe as with HTTPS, with less fuss - just create private keys and make them trusted on the target remote account (in OpenSSH you'd paste "id_rsa.pub" and "id_dsa.pub" from client account to ~/.ssh/authorized_keys2 of target account). Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Threaded servlets okay in a compliant container?
The servlet has access to all information inside the container/context that may be needed to do the job. For an external job this can be much harder. (Iterate over all sessions to do something with them, access attributes with application scope, access attributes from server.xml/ web.xml) It's also easier to protect resources from concurrent access (to synchronize them if nessesary). The actions are triggered locally, the access to the servlet is restricted to local hosts. > -Original Message- > From: Nikola Milutinovic [mailto:[EMAIL PROTECTED] > Sent: Monday, January 05, 2004 12:19 PM > To: Tomcat Users List > Subject: Re: Threaded servlets okay in a compliant container? > > > Why is it easier to do those things from a Servlet, than a > regular shell script? > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Threaded servlets okay in a compliant container?
Ralph Einfeldt wrote: The servlet has access to all information inside the container/context that may be needed to do the job. For an external job this can be much harder. (Iterate over all sessions to do something with them, access attributes with application scope, access attributes from server.xml/ web.xml) It's also easier to protect resources from concurrent access (to synchronize them if nessesary). Aha, I get it - local Tomcat clean-up. Hmm, OK, I guess it makes sense. The actions are triggered locally, the access to the servlet is restricted to local hosts. If the server is a sealed one, with only minimal number of user accounts you should be pretty safe. Although you could implement a simple user/pass authentication, "wget" supports it. Just to make sure that only authorized user account can fire a request from the localhost. Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Threaded servlets okay in a compliant container?
The use of a cron job that does a WGET on a URL that triggers the background processing sounds nice, but what's the process that triggers that on a Windows box that doesn't have cron? A huge power of our application is that it's written in Java and we can run it easily on Windows or Linux or Solaris. Linux and Solaris could allow a cron job, but I'm not a Windows person so I don't know how I'd do the same there. Also, if a process needs to be run every minute, or perhaps even every 5 to 15 seconds (like for processing a work queue), cron would be overkill because it would launch a new process, that process would have to construct the simple URL and the POST it to the system. Also, if someone else also did POSTs to that same URL, they'd also trigger the background processing though it wouldn't be "on schedule" per se. Using cron doesn't sound that much better than just writing a batch C/Java program that does this in a loop so that a process doesn't have to be started each time (though you then have the issue of what to do if the batch program terminates unexpectedly). The key for me is to have a very simple to deploy and manage application, and keeping Tomcat and a database running should be the minimum in our environment, though we probably will also have an Apache web server handling the SSL and static content like javascripts, images, URL rewriting, allowing for easy port 80/443 port listening without having to run as root, and allowing other types of backend apps run, like Perl/CGI or whatever. By far the easiest way to deal with work queues is to allow one thread to insert a transaction into a queue and then notify() the other waiting threads that work has been inserted. But that means that the "work queue thread" is a background thread and thus has issues with being truly compliant now and in the future. By far the easiest way to deal with background tasks is to simply launch a thread that waits() for a certain amount of time and then does work when that times out. Clearly, the cron type solution solves the thread issues, but at the expense of creating another program that needs to be configured and must run and must be checked if it's not running, and causes overhead each time it's launched. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Threaded servlets okay in a compliant container?
David, you can have wget/Scheduled task on Win box -Original Message- From: David Wall [mailto:[EMAIL PROTECTED] Sent: 05 Януари 2004 г. 20:54 To: Tomcat Users List Subject: Re: Threaded servlets okay in a compliant container? The use of a cron job that does a WGET on a URL that triggers the background processing sounds nice, but what's the process that triggers that on a Windows box that doesn't have cron? A huge power of our application is that it's written in Java and we can run it easily on Windows or Linux or Solaris. Linux and Solaris could allow a cron job, but I'm not a Windows person so I don't know how I'd do the same there. Also, if a process needs to be run every minute, or perhaps even every 5 to 15 seconds (like for processing a work queue), cron would be overkill because it would launch a new process, that process would have to construct the simple URL and the POST it to the system. Also, if someone else also did POSTs to that same URL, they'd also trigger the background processing though it wouldn't be "on schedule" per se. Using cron doesn't sound that much better than just writing a batch C/Java program that does this in a loop so that a process doesn't have to be started each time (though you then have the issue of what to do if the batch program terminates unexpectedly). The key for me is to have a very simple to deploy and manage application, and keeping Tomcat and a database running should be the minimum in our environment, though we probably will also have an Apache web server handling the SSL and static content like javascripts, images, URL rewriting, allowing for easy port 80/443 port listening without having to run as root, and allowing other types of backend apps run, like Perl/CGI or whatever. By far the easiest way to deal with work queues is to allow one thread to insert a transaction into a queue and then notify() the other waiting threads that work has been inserted. But that means that the "work queue thread" is a background thread and thus has issues with being truly compliant now and in the future. By far the easiest way to deal with background tasks is to simply launch a thread that waits() for a certain amount of time and then does work when that times out. Clearly, the cron type solution solves the thread issues, but at the expense of creating another program that needs to be configured and must run and must be checked if it's not running, and causes overhead each time it's launched. David - 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]
