• Post Reply Bookmark Topic Watch Topic
  • New Topic

weird behaviour of singleton pattern in rmi call

 
manuel aldana
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,

i am going nuts right now. i implemented a registry as a singleton. the module containing the registry is offering remote functions with rmi.
my problem ist: if the server calls the singleton it has got a different identity as when it gets called from client code accessing offered rmi methods.

because to be sure, i checked this by printing the object-identity (with toString()) right after the call of static getSingleton(). and that results in different values when getting called by running server-module itself or by getting called indirectly of client code.

what is going wrong here? singletons should resists only once in one jvm.

this really does not make sense to me...
so, are there special considerations with singletons when working with rmi?

many thanks
 
Edward Harned
Ranch Hand
Posts: 291
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're not making a lick of sense. RMI is not single threaded. You can't put the RMI Registry inside a singleton since it accepts calls from a port.

Show us a little code.
 
manuel aldana
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sorry for being unprecise.

the singleton has nothing to do with the rmi registry (which is managed with LocateRegistry.createReagistry() in a rmi startup class).

the singleton is a container for card-objects, which should exist only once in a jvm and must resist in a card-registry object. so all services which are accessing my rmi-implementation and its internal objects must use the same card-registry. that is the reason why it is implementend as a singleton.

my problem is: if i call CardRegistry.getRegistry() from my server classes i get a different object (and different card-objects) as when i call CardRegistry.getRegistry() from rmi clients.

the implementation of singleton is as usual:


that is a very weird behaviour and i want to ensure that my conception of object-identity with singletons is right and want to exclude, that my problem has to do with rmi.

maybe somehow rmi is leasing my objects and destroying static fields and therefore my singleton... the cardRegistry is a field of an implementation class of a remote interface.

thanks again.
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your code is not thread safe. Try adding the synchronized keyword to your getRegistry() method and see if that cures the problem. If it doesn't, then there may be a class loading problem.
 
manuel aldana
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sorry, i forgot post the right code. of course i added a synchronized in my real code.

but the classloader problem is a good hint, because: rmi-server and rmi-client are two eclipse projects, but (as i remember correctly) rmi-client still references rmi-server as a project dependency in eclipse buildpath.
that is because before switching to rmi i split my one big project into two to refactor to a client-server version. and client project still references server project it could run without rmi. and as far as i remember i forgot to remove this buildpath dependency after adding rmi functionality.

at monday at work i will have a look and will post again.
 
manuel aldana
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yes, as guessed eclipse project references had been the problem.

because singleton class was still referenced, rmi-client found this in its local classpath and therefore a different static variable was used.
 
Oricio Ocle
Ranch Hand
Posts: 284
Debian Firefox Browser Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello guys
Originally posted by manuel aldana:
yes, as guessed eclipse project references had been the problem.

because singleton class was still referenced, rmi-client found this in its local classpath and therefore a different static variable was used.

that is neither an Eclipse specific problem nor a classpath problem. Client and server are running in different JVMs each with its own static variables.
If you post more code we can help you better
Cheers
 
manuel aldana
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
that is neither an Eclipse specific problem nor a classpath problem. Client and server are running in different JVMs each with its own static variables.


yes that was the problem. because client+server were running on two JVMs the client referred to its own static variable instead of using indirectly the one of the server. that was because i included the server as a project reference (singleton class could be found in classpath), so it did not use the remote server but used its own "local" instance.
 
Oricio Ocle
Ranch Hand
Posts: 284
Debian Firefox Browser Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yes that was the problem. because client+server were running on two JVMs the client referred to its own static variable instead of using indirectly the one of the server. that was because i included the server as a project reference (singleton class could be found in classpath), so it did not use the remote server but used its own "local" instance.

I cant figure how exactly the scenario is.
Running your eclipse client project, the classloader load first client project classes and then, over referenced proyects, shadows repeated classes.
So i cant see why this could be the problem.

Have not clear your implementation.

Does your CardRegistry implement Remote?
If so have in mind that your client should use the server CardRegistry stub and not a local class version.
I would use CardRegistry:CardRegistryFactory.getCardRegistry() as service locator at client layer, and implement here singleton behaviour.
[ September 12, 2007: Message edited by: Oricio Ocle ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!