Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

putting servlets to sleep

 
N Goldsmith
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a number of servlets that all need to share the same resource (contraint of our legacy system). All the servlets call into a shared singleton object (called the concentrator) to queue up their message for the legacy system. Each servlet needs to wait to get a response back. What I want the concentrator to do when I get a request from the servlet, is put each servlet to sleep until the response comes back (or the timeout is exceeded). Then it will wake them up and return the data. Each servlet will have a unique request ID.

This may even be just a Java question, but I wasn't sure if Servlets behaved differently in this case.

Can anyone recommend how I might go about putting the servlet to sleep? Is it a simple thread question?

thanks

[ November 17, 2004: Message edited by: N Goldsmith ]
[ November 17, 2004: Message edited by: N Goldsmith ]
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64631
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd step back and approach the issue differently. Stalling a servlet will wreak havoc on your server.
 
Jayesh Lalwani
Ranch Hand
Posts: 502
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm a little confused by your question. DO you want to put the entire servlet to sleep, or you want to put the particular request to sleep?

As Bear said, stalling the entire servlet will cause problems because clients might keep requesting data which will result in too many requests

If you want a specific request to go to sleep, you need to do make your request wait while your concentrator is working on the request

Somthing like this


[ November 17, 2004: Message edited by: Jayesh Lalwani ]
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think Bear is thinking of that, plus a lot more. Like Http connections are supposed to not wait that long. Plus doesn't the container only have one instance of the Servlet, and putting that to sleep would disallow others from making requests.

It sounds like you are more trying to send an asynchronous message, which would be better solved with Message Driven Beans and not Servlets.

It really is more an architecture question as to whether you want to use Servlets for this kind of action. Or have a Servlet call an EJB, and do the work there, the response won't return until the EJB is finished

Mark
 
N Goldsmith
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks guys!

I should have mentioned, I don't want to put the entire servlet to sleep. I want to put just the particular thread the HTTP request came in on. The servlet will still be available to handle new requests. The length of time it will be asleep will be an extremely short duration before the timeout kicks in and an error is logged.

I think Jayesh's code snippet will do the trick. I'll give it a shot and see how it goes.

thanks
 
Jayesh Lalwani
Ranch Hand
Posts: 502
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by N Goldsmith:
Thanks guys!

I should have mentioned, I don't want to put the entire servlet to sleep. I want to put just the particular thread the HTTP request came in on. The servlet will still be available to handle new requests. The length of time it will be asleep will be an extremely short duration before the timeout kicks in and an error is logged.

I think Jayesh's code snippet will do the trick. I'll give it a shot and see how it goes.

thanks


I would still recommend not putting the thread to sleep though. Most browsers will timeout waiting for the servlet to respond. Also, you dont want threads building up on you server. Too many threads might result in too many context switches, which will degrade your performance. It all depends on how large yout timeout is. If your timeout is large, a more efficient way would be respond back to the client as soon as you start the process, and then provide another interface for the client to monitor the progress of the job. So, even if you dont want to change your requirements, be aware that putting threads to sleep like this might be a drain on the server's resources.
 
N Goldsmith
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, I'll look at both routes, thanks.

I'm having a little problem with the code snippet. When I call the jobCompleted callback from my concentrator, I have an illegal thread access trying to notify on the gate. I was under the assumption that synchronzing would allow another thread to do a notify. Did I do something incorrect?




Here is what the concentrator does:
//figure out who owned the cmd and send them the message



[ November 18, 2004: Message edited by: N Goldsmith ]

[ November 18, 2004: Message edited by: N Goldsmith ]

[ November 18, 2004: Message edited by: N Goldsmith ]
[ November 18, 2004: Message edited by: N Goldsmith ]
 
Jayesh Lalwani
Ranch Hand
Posts: 502
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oops.. I'm getting a little bit rusty with Thread API. I think you have to put a synchronized(gate) block around your call to gate.notify() . If I remember correctly, a thread has to own the gate before it can call notify on it
 
N Goldsmith
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ah, that did it. It's obvious to me now. Thanks for all your help.
 
Consider Paul's rocket mass heater.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic