Wim, At the low level this can be achieved by registering instances of the java.util.concurrent.Executor interface (from the Java 5 concurrency libs) as services -- then a bundle wishing to execute work can submit it to a registered Executor rather than explicitly create its own threads. The problem with this approach is it gives us very limited options for tracking the progress of work units. We can submit instances of FutureTask, but these only allow us to check for completion by polling or blocking. Eclipse has a "Jobs" framework which offers lots of improvements in this area, and I believe it can be used in a standalone OSGi runtime, i.e. without lots of dependencies on other parts of Eclipse.
Does this need to be an OSGi specification? I'm not sure... Executor is already specified by the JCP, and for remote execution it may be enough to use Executor with D-OSGi. There may be some value in standardising Eclipse's Jobs framework though. Neil On Thu, Feb 11, 2010 at 11:41 AM, Wim Jongman <[email protected]> wrote: > Greetings, > > At Remain Software, we are currently in need for a queuing mechanism. > AFAIK there is no such thing inside OSGi which in my opinion would be > a nice spec. The spec would define jobs to be queued and scheduled > across multiple job queues. Queues would allow n jobs to be executed > at once and so one. > > The job queue definition can/will be very broad, think multiple cores, > mulitple VM's, remote VM's --> make use of the idle time of all office > computers, etc.. > > Google search gives no such thing. Can I have your opinions, > corrections and directions. > > Best regards, > > Wim Jongman > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
