[concurrency-interest] ThreadPoolExecutor - Concurrent "Batch" Executions
mboyers at yahoo.com
Thu May 20 07:48:19 EDT 2010
Yes, thanks. I had a feeling it was right in front of me, which is what prompted me to ask (even though I'm embarrassed that it's a method in the very class I was looking at).
I notice that when using invokeAll and setting a timeout, it will cancel any tasks that haven't completed if it does indeed time out. In my case, I'm thinking there may be value in going ahead and letting them complete, because the remote response will be cached and will likely be useful for on a subsequent request -- i.e., letting it complete could save me from having to make the same remote call later on.
--- On Thu, 5/20/10, Martin Buchholz <martinrb at google.com> wrote:
> From: Martin Buchholz <martinrb at google.com>
> Subject: Re: [concurrency-interest] ThreadPoolExecutor - Concurrent "Batch" Executions
> To: "Mike Boyers" <mboyers at yahoo.com>
> Cc: concurrency-interest at cs.oswego.edu
> Date: Thursday, May 20, 2010, 1:47 AM
> Is this what you're looking for?
> long, java.util.concurrent.TimeUnit)
> On Wed, May 19, 2010 at 20:13, Mike Boyers <mboyers at yahoo.com>
> > I'm building a service where, in order to generate
> each response, I'll need to go against several remote
> sources. In many cases, the remote requests can be made
> > I'm looking for a super simple interface where
> developers can execute these remote requests in parallel
> while being blocked as they execute, with the ability to
> time out after a specified period.
> > As a (very) rough idea:
> > Collection batch = new LinkedList();
> > batch.add(new RemoteRequest1());
> > batch.add(new RemoteRequest2());
> > batch.add(new RemoteRequest3());
> > Batcher.execute(batch, 5, TimeUnit.SECONDS);
> > The Batcher.execute call blocks until either all of
> the tasks are complete or until 10 seconds passes.
> > I can see how to use a ThreadPoolExecutor to
> accomplish this, by submitting each Callable then waiting on
> the Future objects returned upon submit, meanwhile keeping
> track of the overall amount of time I've waited as I wait on
> each Future. While this logic isn't overly complicated,
> I'd still like to keep it housed and supply developers with
> something like I outlined above.
> > But before building this "wrapper", I figure I'd ask
> to see if there's already something existing I should be
> looking at, either in the concurrent package or elsewhere
> (or if I should be thinking about this in a completely
> different way).
> > Thanks,
> > Mike
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
More information about the Concurrency-interest