However, with the "executors", they (aside from DirectExecutor or whatever it's called) do not run the operation (the Runnable object) within the calling thread. In essence, they're typically asynchronous. The service models need to be synchronous, unless you want to block the calling thread and wait until the executor finishes executing the runnable task, but then why would you use an executor in the first place? Anyway, if you were just using the ThreadPoolExecutor as an example of the kinds of parameters/settings we should have available on the threaded service model, I agree, but I don't think that using the ThreadPoolExecutor is the answer.
-----Original Message----- From: Marcus Brito [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 7:11 AM To: [email protected] Subject: Re: Pooled Service Model enhancements > Do other people in this list think such a kind of pooled model would be > worth? Right now none of my services are using the pooled model, but I can see how/when it could be used. There's another project (which is not using hivemind) that would benefit greatly from this model. >>From my point of view, the "concurrent executors" kind of services would benefit the best from this model -- and if we're serious about this there's more than just a minimum and a maximum number of instances. We need to configure timeouts, queues, etc. In other words, we just need a service model that works like a java.util.concurrent.ThreadPoolExecutor :) -- Marcus Brito <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
