Обсуждение: Multi-threaded servlet environment
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. 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? For example, while I understand the need for a request to drive servlets, even WEB-INF/web.xml allows me to configure servlets that are invoked when the system is started, for example, and the need for background processing tasks is quite common in even mildly sophisticated applications (like threads that check for changed or new files locally or via URLs, or do backups, or find old data that can be automatically deleted, or for sending alerts to people after so much time has passed, unlocking a blocked activity after so much time has passed, etc.). It's quite easy to create new threads that wake up periodically and perform a myriad of application chores that are outside of the scope of an external event driving a transaction. My application could be streamlined quite a bit if I could get rid of a standalone Java application that does those server-based tasks on behalf of the servlet application. Thanks, David
David, There's no problem creating threads inside a servlet container. Dave On Mon, 2003-12-29 at 20:09, David Wall wrote: > 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. > > 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? > > For example, while I understand the need for a request to drive servlets, > even WEB-INF/web.xml allows me to configure servlets that are invoked when > the system is started, for example, and the need for background processing > tasks is quite common in even mildly sophisticated applications (like > threads that check for changed or new files locally or via URLs, or do > backups, or find old data that can be automatically deleted, or for sending > alerts to people after so much time has passed, unlocking a blocked activity > after so much time has passed, etc.). It's quite easy to create new threads > that wake up periodically and perform a myriad of application chores that > are outside of the scope of an external event driving a transaction. > > My application could be streamlined quite a bit if I could get rid of a > standalone Java application that does those server-based tasks on behalf of > the servlet application. > > Thanks, > David > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Dave Cramer 519 939 0336 ICQ # 1467551
We were about to lose a support agreement with BAE/Weblogic people simply because we were creating threads on our own. No reasons were given to us, but they (BES) simply don't *recommend* the arbitrary creation of threads. I suspect it's this way because people can easily create lots of leaks, excessive CPU usage or something like that and then blame the application server for its ridiculous performance. > David, > > There's no problem creating threads inside a servlet container. > > Dave >
I'm surprised by BEA's response to you. We create our own threads to manage background tasks (mainly interacting with the database). These threads are started by a servlet which is initialized when the servlet container starts using the <load-on-startup> in the servlet tag in web.xml We also place code in the (same) servlet's destroy() method to set flags and interrupt our threads to get them to complete and then quit. This way the servlet container is able to shutdown gracefully. AFAIK, we've not had any problems with this approach, and it meant that we didn't have to write a separate app to manage the background processes. Also, you can use the (same) servlet to display processing information from the threads - this can be very useful to see what's going on. John Sidney-Woollett Marcus Andree S. Magalhaes said: > > We were about to lose a support agreement with BAE/Weblogic people > simply because we were creating threads on our own. No reasons > were given to us, but they (BES) simply don't *recommend* the > arbitrary creation of threads. > > I suspect it's this way because people can easily create lots of > leaks, excessive CPU usage or something like that and then blame > the application server for its ridiculous performance. > > > >> David, >> >> There's no problem creating threads inside a servlet container. >> >> Dave >> > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html >
On 30/12/2003 06:59 Marcus Andree S. Magalhaes wrote: > > We were about to lose a support agreement with BAE/Weblogic people > simply because we were creating threads on our own. No reasons > were given to us, but they (BES) simply don't *recommend* the > arbitrary creation of threads. > > I suspect it's this way because people can easily create lots of > leaks, excessive CPU usage or something like that and then blame > the application server for its ridiculous performance. EJB containers need to have full control of object lifecycles so creating your own threads may cause problems. OTOH, web-only containers don't have such rigid requirements so creating your own threads is fine in Tomcat (I do this quite a bit without a problem). HTH -- Paul Thomas +------------------------------+---------------------------------------------+ | Thomas Micro Systems Limited | Software Solutions for the Smaller Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +------------------------------+---------------------------------------------+
"David Wall" <d.wall@computer.org> writes: > 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. > > 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? This is not the forum to be asking this question. Mail me offline if you need more help. In breif the answer is that there is no problem with launching threads inside servlet containers. There is no spec prohibition (I served on the spec team until recently). Nic
Marcus, That's simply amazing, that anyone would prohibit you from writing legal java inside a container. Have a look at jboss, and see if it can solve your problems. Dave On Tue, 2003-12-30 at 01:59, Marcus Andree S. Magalhaes wrote: > We were about to lose a support agreement with BAE/Weblogic people > simply because we were creating threads on our own. No reasons > were given to us, but they (BES) simply don't *recommend* the > arbitrary creation of threads. > > I suspect it's this way because people can easily create lots of > leaks, excessive CPU usage or something like that and then blame > the application server for its ridiculous performance. > > > > > David, > > > > There's no problem creating threads inside a servlet container. > > > > Dave > > > > > -- Dave Cramer 519 939 0336 ICQ # 1467551
FYI since I posted this to the wrong list you might be interested in this answer. It does call into question whether using threads is really going to be a problem or whether user-created threads will be allowed. It does seem silly to say we can't use threads since all background processing requires it, and nothing but the most trivial of web sites would have no background processing needs. Nic, how does this jive with your statement that the specs don't say anything like this? Are we misunderstanding what is implied here? Thanks, David ----- Original Message ----- From: "Tim Funk" <funkman@joedog.org> To: "Tomcat Users List" <tomcat-user@jakarta.apache.org> Sent: Tuesday, December 30, 2003 9:32 AM Subject: 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
On Tuesday 30 December 2003 09:42, Dave Cramer wrote:
> Marcus,
>
> That's simply amazing, that anyone would prohibit you from writing legal
> java inside a container.
>
Well, the point is that you usually can create your own threads. However, as
someone else mentioned before, creating threads in the EJB tier of a J2EE
container is discouraged according to the spec. Reasons are many, but mainly
boil down to issues of resource management, where resources are things like
database- or JMS connections, and EJB instances. Another fairly important
aspect is security; the container has no way of knowing what the principal
associated with the thread is, so it cannot determine if it actually is
allowed to access said resources.
That said, threads not accessing any container resources (database/JMS
connections, EJBs, etc) are usually not a problem.
> Have a look at jboss, and see if it can solve your problems.
JBoss needs an ugly hack (a static method needs to be called) to set the
proper security context on a thread.
>
> Dave
JdV!!
>
> On Tue, 2003-12-30 at 01:59, Marcus Andree S. Magalhaes wrote:
> > We were about to lose a support agreement with BAE/Weblogic people
> > simply because we were creating threads on our own. No reasons
> > were given to us, but they (BES) simply don't *recommend* the
> > arbitrary creation of threads.
> >
> > I suspect it's this way because people can easily create lots of
> > leaks, excessive CPU usage or something like that and then blame
> > the application server for its ridiculous performance.
> >
> > > David,
> > >
> > > There's no problem creating threads inside a servlet container.
> > >
> > > Dave
--
==============================================================
Jan de Visser Digital Fairway Corp.
tel. (416) 628 7525 jdevisser@digitalfairway.com
<Enter any 12 digit prime to continue>
==============================================================
Well, I found that amazing too. JBoss could help us, but the reasons why Weblogic was chosen reside on the political side... It's a bit difficult to push OpenSource software in large, slow motion and intelectually old corporations. > Marcus, > > That's simply amazing, that anyone would prohibit you from writing legal > java inside a container. > > Have a look at jboss, and see if it can solve your problems. > > Dave > On Tue, 2003-12-30 at 01:59, Marcus Andree S. Magalhaes wrote: >> We were about to lose a support agreement with BAE/Weblogic people >> simply because we were creating threads on our own. No reasons >> were given to us, but they (BES) simply don't *recommend* the >> arbitrary creation of threads. >> >> I suspect it's this way because people can easily create lots of >> leaks, excessive CPU usage or something like that and then blame the >> application server for its ridiculous performance. >> >> >> >> > David, >> > >> > There's no problem creating threads inside a servlet container. >> > >> > Dave >> > >> >> >> > -- > Dave Cramer > 519 939 0336 > ICQ # 1467551
"David Wall" <d.wall@computer.org> writes: > FYI since I posted this to the wrong list you might be interested in this > answer. It does call into question whether using threads is really going to > be a problem or whether user-created threads will be allowed. It does seem > silly to say we can't use threads since all background processing requires > it, and nothing but the most trivial of web sites would have no background > processing needs. > > Nic, how does this jive with your statement that the specs don't say > anything like this? Are we misunderstanding what is implied here? The spec does not prohibit the creation of threads in servlets. It makes it quite clear that the decision is for the container implementor. If you're interested the reason we put it in (if I remember correctly) is that thread limiting would be necessary for some session sharing environments. Nic