Hi, The Eclipse jobs framework is a good start (in particular the monitor class) but not the thing to use for industrial strength job queuing. There is just one queue and the jobs type basically determine the priority of execution. There is no control over how the job should physically be executed. Jobs that are unresponsive can never be removed (http://bugs.eclipse.org/123075)
I would say that the job queue is responsible for using the concurrency API or anything else that is considered good for the purpose (e.g. if you run in a Foundation VM). However, having looked better at the Executor interface and subclasses, it is very rich but, as you say, lacks monitoring. This will provide a good starting point. Wim On Thu, Feb 11, 2010 at 1:08 PM, Neil Bartlett <[email protected]> wrote: > 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 > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
