Hi Guillermo,
The wait loop idiom:
synchronized(obj){
while( condition does not hold ){
obj.wait();
// do stuff we were waiting for
}
Without the loop, your threads wait automatically and depend on obj.notify
getting called from some control thread, which I think is never happening or
is happening before these threads actually get to the wait statement, or a
control thread is never releasing the lock, many other possibilities that
without seeing the code it's quite pointless to speculate further.
In any case, I would take a different approach and use the concurrency
package and perhaps the Executors.newCachedThreadPool or newFixedThreadPool
factories. Basically, start one of these up, wrap the third party lib work
in a Runnable or Callable annonymous inner class then submit it to the
executor. The executor returns a Future object that you can perform a timed
blocking wait on it for it to finish it's work, if it doesn't finish in some
timeframe it throws an exception (but the task is free to finish) and you
should maybe send a 202 Accepted return code.
public void handleGet(){
// perhaps start this pool in the application createRoot
// and add it to the context attributes map.
// you must call execution.shutdown() when the
// component is stopped.
ExecutorService executor =
getContext().getAttributes().get("3rdPartyThreadPool");
final Request req = getRequest();
Future<Foo> pendingResult =
executor.submit( new Callable<Foo>(){
public Foo call(){
Foo result = null;
// do 3rd party lib work here, use req variable.
return result;
}
});
try{
Foo theResult = pendingResult.get(waitTime, timeunit);
// getResponse().setEntity(theResult);
}catch (TimeoutException ex){
// what is plan B? return 202
}
}
Another option is to abstract the third party lib work as a resource ticket.
When you make a request you are actually making a request for a ticket to
process the work now or later. This would be a POST request for creating a
new resource ticket (one that the user is not allowed to predetermine the
resulting URI). The POST returns a 201 created with a URI of the new
resource ticket. Then subsequent calls to that particular ticket's URI would
return the status of the that third party lib result (pending, finished,
error, etc) potentially enclosing the actual 3rd party lib result.
Joe.
----- Original Message -----
From: "Guillermo Cantu" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, June 20, 2008 7:14 PM
Subject: Calling wait() in a handleGet in a Resource, blocks all other
requests?
Hi,
My problem is that I need a pool manager to control the number of
instances of
a 3rd party library that are loaded to service the requests. Each request
needs
an instance of the 3rd party library.
So let's say I can service 10 requests at a time. I need to make the other
requests wait while an instance of the library is freed.
From what I've been reading, this can't be easily accomplished. If I use a
thread pool manager to manage the requests, a response will be
automatically
returned when the handle method returns.
So what I'm trying to do is to block the Resource that handles each
request, in
the handleGet method, so it won't return until the request has been
serviced.
The problem now is that when calling wait() inside the handleGet method,
the
other requests are not processed until after that handleGet returns.
As I understand from the documentation, each Resource has it's own thread,
right? So shouldn't the other requests be handled while the first one is
waiting?
Inside handleGet I'm using:
synchronized (this)
{
this.wait();
}
Thanks!
