Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Threads/servlets/long task  RSS feed

 
trebor iksrazal
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!