Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S: RMI agent identification

 
Jarek Losice
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello there,

I'm wondering which approach to identify agents (client program connecting to RMI sever) is correct/better:

- when an agent connects to server it receives a AID (agent id) and all the following calls must be done with that given AID - this is a way for a server to match some resource (let's call it RES for clarity, it will be some kind of a wrapped RandomAccessFile instance) to this particular agent. Benefits: 1 RES per working agent. Problems: a way to find out that agent disconnected, to release this 1 RES.

- create separate 1 RES per calling thread. As we know, single RMI client's call can be dispatched with different RMI server threads. So we can make no assumption of which agent is calling a particular method and do not bother with AIDs. Instead, we can allocated 1 RES per calling thread. When an RMI method call is being made a server code checks if current thread has it's RES assigned and ready, if so it proceeds, if not it creates one. Benefits: simplicity, Problems: if we imagine a RMI server implementation which creates new thread per each RMI call, and disposes this thread after the call is done, then we have a problem, because there's gonna be a bunch of RES instances created for threads that are already gone. But maybe we could periodically check if these threads are alive (Thread.isAlive) and release RES instances for these dead threads?

What do you think?
Thank you for any comments.

Jarek.

 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jarek,

I guess you don't have an interface with a lockCookie, because that would solve your problem My interface also didn't have such a lockCookie, so I had to come up with some solution and I was inspired by this solution by Roberto Perillo.

You could also use the RMI Factory design pattern (like in Andrew's book). And I think this one is also a simple and elegant solution, dealing with the biggest problem of RMI (for this assignment that is).

Kind regards,
Roel
 
Jarek Losice
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Roel,

thanks for your prompt reply. Yes, given interface uses a lockCookie concept, but it's not a problem.

In my solution I'm assigning a RandomAccessFile instance (wrapped in higher level layer class - lets call it WorkerImpl.) for each working RMI server thread. This is to assure high level of concurrency in DB file acces. So I end up in having a Map<Thread, WorkerImpl> in my solution.
I'm concerned with resource usage in some pesimistic scenario: if one would use a RMI implementation which for every method call creates a new thread, after this call is done shuts this thread down (I know this is silly approach for a RMI server implementation, but as you know RMI specification does not state anything about thread management, so I guess, we should assume that even such a mad approach could be used by someone), then we have a problem. Because this map would keep growing and growing - it would also make Thread objects undisposable for garbage collector, as mentioned map keeps references to them.
I know that "real" RMI implementation does not behave this way, but this is NOT due to specification, it's due to sound implementation.

What do you think?
Thanks,

Jarek.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jarek,

I don't see the whole point and purpose of your approach. You have the lockCookie in your interface to make sure the record is updated by the same client who owns the lock on that record. Just make sure your Data class is thread-safe and it can handle concurrent requests and you are good to go.

Kind regards,
Roel
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic