Threads/servlets/long task

[trebor iksrazal]

The problem:

1) Tomcat 3.3, struts, web client.
2) Launch the printing of 1000 (yes, one thousand) pdf files.

One developers idea is to return a response immediately - after
launching background threads to complete the tasks.

My intuition is that this a bad idea for at least one reason:

The servlet spec, as I understand it, allows a servlet container to
stop (destroy) an inactive servlet thread anytime it feels like it.

My question: what happens to background threads if the servlet is
detroyed by the container? Is this a likely scenerio in this
situation? Does the choice of daemon or non-daemon threads make the
solution any cleaner?

My immediate suggestion was to use JMS, which I myself have used a lot
in servlets but this project is a bit scared of JMS. I also have
doubts Tomcat 3.3 could support it. (I've used openJMS a lot with
tomcat 4.x).

iksrazal

[Peter den Haan]

Originally posted by trebor iksrazal:
My question: what happens to background threads if the servlet is
detroyed by the container? Is this a likely scenerio in this
situation? Does the choice of daemon or non-daemon threads make the
solution any cleaner?

Nothing at all will happen to the background threads. The difference between daemon and non-daemon threads is important only when the application server stops - executing non-daemon threads (i.e. unfinished print jobs) will prevent the application server from stopping. But if you are really printing lots of pdf files simultaneously you won't want to swamp your system with that many threads and printing actions; you would use a thread pool or...

Originally posted by trebor iksrazal:
My immediate suggestion was to use JMS, which I myself have used a lot
in servlets but this project is a bit scared of JMS.

... or JMS. I would agree that JMS is an excellent choice here. It rids you of threading concerns, you can set up as many consumers as you want parallel print jobs, and you can scale it from a simple in-memory JMS implementation to a full-blown persistent one with the consumers running in a separate process or even a separate machine.

Not sure why a project would be "scared of JMS". Sounds a bit like craftsmen being scared of screwdrivers: when all you have is a hammer...

- Peter