Thread: Multi-threaded servlet environment

Multi-threaded servlet environment

From
"David Wall"
Date:
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


Re: Multi-threaded servlet environment

From
Dave Cramer
Date:
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


Re: Multi-threaded servlet environment

From
"Marcus Andree S. Magalhaes"
Date:
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
>




Re: Multi-threaded servlet environment

From
"John Sidney-Woollett"
Date:
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
>


Re: Multi-threaded servlet environment

From
Paul Thomas
Date:
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   |
+------------------------------+---------------------------------------------+

Re: Multi-threaded servlet environment

From
Nic Ferrier
Date:
"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

Re: Multi-threaded servlet environment

From
Dave Cramer
Date:
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


Re: Multi-threaded servlet environment

From
"David Wall"
Date:
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


Re: Multi-threaded servlet environment

From
Jan de Visser
Date:
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>
==============================================================

Re: Multi-threaded servlet environment

From
"Marcus Andree S. Magalhaes"
Date:
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




Re: Multi-threaded servlet environment

From
Nic Ferrier
Date:
"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