1

I'm trying to use Jini, in a "Masters/Workers" arrangement, but the Worker jobs may be long running. In addition, each worker needs to have exclusive access to a singleton resource on that machine.

As it stands, if a Worker receives another request while a previous request is running, then the new request is accepted and executed in a second thread.

Are there any best-practices to ensure that a Worker accepts no further jobs until the current job is complete?

Things I've considered:

  • synchronize the job on the server, with a lock on the singleton resource. This would work, but is far from ideal. A call from a Master would block until the current Worker thread completes, even if other Workers become free in the meantime
  • unregister the Worker from the registry while the job is running, then re-register when it completes. Might work OK, but something doesn't smell right with this idea...

Of course, I'm quite happy to be told that there are more appropriate technologies than Jini... but I wouldn't want anything too heavyweight, like rolling out EJB containers all over the place.

0

2 Answers 2

1

The "Masters/Workers" pattern you link to is clearly not what you're implementing, because that uses a JavaSpace as an intermediate store for requests and results, thus making your problem disappear.

And indeed that's the standard solution for this kind of scenario: a queue to which "Masters" add requests and from which "Workers" take requests to process.

0

To answer my own question, and probably earn myself a "breaking Stack Exchange etiquette" badge...:

A service can unexport itself from the registry to prevent it being requested again.

See:

Exporter.unexport(bool)

In this instance, I need to pass "true" so the unexport happens immediately - otherwise it'll wait until the current call completes, defeating the object of this exercise. I'll probably synchronize access to the whole server object too, in a half-arsed attempt to prevent a "two calls happen at the same time" race.

2
  • Note: if a service unexports itself, it's not easy to get it re-exported. Think I'll instead add a ServiceItem to the server to say that it's busy, and filter out those busy servers with a ServiceTemplate on the clients.
    – anon
    Commented May 4, 2012 at 7:22
  • this approach looks vulnerable for race conditions. If second job happens before unexport, you're in for a trouble aren't you?
    – gnat
    Commented May 4, 2012 at 11:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.