• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Threads/servlets/long task

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic