mutithreading in webapps

[ameyas7]

hi all,

i was trying to implement a design which is like dispatcher, worker
model where N number of requests come in, which are queued for the
dispatcher to pick them up and spawn a worker thread to process each
of these requests. of course we will use thread pool for worker
threads.
but i was told that issues might occur with multi threading in webapp.
i am using Tomcat container. is it not advisable to go for such multi
threaded designs in webapps / tomcat ?
one reason could be since webapps typically run for longeeeeeerrrr
period of time than usual desktop apps so the chances of memory leaks
or inappropriate resource handling might affect adversely in webapps
with muti-threaded design.

has anyone experienced such problems with threads in tomcat ?

thanks


amey

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

i was trying to implement a design which is like dispatcher, worker
model where N number of requests come in, which are queued for the
dispatcher to pick them up and spawn a worker thread to process each
of these requests. of course we will use thread pool for worker
threads.
but i was told that issues might occur with multi threading in webapp.
i am using Tomcat container. is it not advisable to go for such multi
threaded designs in webapps / tomcat ?
one reason could be since webapps typically run for longeeeeeerrrr
period of time than usual desktop apps so the chances of memory leaks
or inappropriate resource handling might affect adversely in webapps
with muti-threaded design.

has anyone experienced such problems with threads in tomcat ?

Servlet containers are intended for:
- web request comes in
- web response go back out

They are not intended for long time number crunching or such.

The container uses threading itself to serve multiple requests
in parallel.

It is legal according to the spec to start multiple threads, so
you could:
- web request comes in
- you start N threads
- you wait to all threads are done
- web response go back out

But if it takes a long time, the the browser will consider
it a timeout.

So it is not a problem whether multi threading will work in Tomcat - it
is a question whether it is a good way of solving the problem.

Arne

 

[Daniel Pitts]

Servlet containers are intended for:
- web request comes in
- web response go back out

They are not intended for long time number crunching or such.

The container uses threading itself to serve multiple requests
in parallel.

It is legal according to the spec to start multiple threads, so
you could:
- web request comes in
- you start N threads
- you wait to all threads are done
- web response go back out

But if it takes a long time, the the browser will consider
it a timeout.

So it is not a problem whether multi threading will work in Tomcat - it
is a question whether it is a good way of solving the problem.

Arne

It is doable (and we've done it where I work). Although, you might
consider having a separate standalone process (in a different JVM)
handle the actual work.

 

[ameyas7]

It is legal according to the spec to start multiple threads, so
you could:
- web request comes in
- you start N threads
- you wait to all threads are done
- web response go back out

But if it takes a long time, the the browser will consider
it a timeout.

So it is not a problem whether multi threading will work in Tomcat - it
is a question whether it is a good way of solving the problem.

Arne

well my web request will not be waiting till the job is done.
it is actually a notification service, ppl will keep posting it and
then it will pick up all queued requests and notify the recepients
(say by mail or other means)
so the web response is not blocked on the completion of the worker
thread.


amey

 

[ameyas7]

It is doable (and we've done it where I work). Although, you might

consider having a separate standalone process (in a different JVM)
handle the actual work.-

Hi Daniel,

any specific reason that you can mention for running it in different
JVM? do you think it might make the core webapp unstable ?
i am actually writing a notification service where ppl will post
request to the service which will notify to the intended recepients
(by mails or other means)

thanks.

amey

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

well my web request will not be waiting till the job is done.
it is actually a notification service, ppl will keep posting it and
then it will pick up all queued requests and notify the recepients
(say by mail or other means)
so the web response is not blocked on the completion of the worker
thread.

If you could upgrade from a servlet container (Tomcat) to a full
J2EE application server (like JBoss with Tomcat embedded as servlet
container), then you could:
- web request comes in
- servlet queue task to message queue
- web response go back out
- a message driven bean process the input from the message queue

Your solution will also work, but I believe the above is "the J2EE way".

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

It is doable (and we've done it where I work). Although, you might
consider having a separate standalone process (in a different JVM)
handle the actual work.

I know it is doable. But it is not the usage servlet containers
were designed for.

Arne

 

[Mike Schilling]

well my web request will not be waiting till the job is done.
it is actually a notification service, ppl will keep posting it and
then it will pick up all queued requests and notify the recepients
(say by mail or other means)
so the web response is not blocked on the completion of the worker
thread.

This can be made to work inside Tomca, but there are subtle isses.

1. You need to make your background threads daemon threads, or normal Tomcat
shutdown won't work, because even after all messages are done processing,
your threads will still be active.
2. If your application is stopped using Tomcat's mangement interface, your
background threads should stop too. You need to hook the Servelet.destroy()
method to accomplish this.