Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

migrated from stackoverflow.com May 3 '12 at 15:13

This question came from our site for professional and enthusiast programmers.

1  
+1 simply for asking a Jini question. –  user1249 Jun 3 '12 at 8:07

2 Answers 2

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.

share|improve this answer

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.

share|improve this answer
    
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. –  Matthew Flint May 4 '12 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 May 4 '12 at 11:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.