• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Static reference to my remote service implementation to avoid java.rmi.NoSuchObjectException

 
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was reading about the need to keep a static reference to your remote service implementation in order to avoid it being garbage collected and thus causing an java.rmi.NoSuchObjectException.

So adding a static field prevents the GC from removing this object. That makes sense. But I am just wondering where did people place this static field? Was the field in a static class?
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I kept the static reference in the class that's used to start the RMI-server.
 
Sean Keane
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Roel De Nijs wrote:I kept the static reference in the class that's used to start the RMI-server.



Was that a static class?
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sean Keane wrote:Was that a static class?


No
 
Sean Keane
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Static class? Apologies, disregard that. I think I was still asleep !
 
Sean Keane
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Roel De Nijs wrote:I kept the static reference in the class that's used to start the RMI-server.



Ok, now I figured out what I meant to ask you! But firstly, nice find . I've not seen this mentioned in any tutorial or book that I've read on RMI. It is obviously quite important!

You have a class that you use to start the RMI-server. Do you actually create an instance of this class or it is just a utility class with static methods?

I am guessing that it is the latter. You have a static method to start the RMI-server. That is why you have to store your RemoteBusinessLogicImpl instance as a static variable.

Another Approach

If the whole idea is to prevent the JVM from GC'ing (Garbage Collecting) your instance of RemoteBusinessLogicImpl then there is one more logical place to put it. Place a reference to it in your server GUI as an instance variable rather than a static.

Making the a static reference to the instance of RemoteBusinessLogicImpl is not what prevents it from being GC'd. It is keeping a reference to it that prevents the JVM from GC'ing the instance of RemoteBusinessLogicImpl . Creating a static reference is not the key point. That reference could be a static field or an instance field. The key point is creating a reference that will exist for the lifetime of the server.

You can be guaranteed that your instance of RemoteBusinessLogicImpl will not be GC'd if you assign it to an instance variable of your server GUI class.

An Example

So you would have...


Benefits of Other Approach

Nice separation of concerns. The RemoteBusinessLogic lives with the server window which it relates to - logical one-to-one association here. The registry is created - no need to wrap a one liner inside a custom class. The register-method is a static method that is only concerned with registering the remote service - it makes no sense for such a class to hold a state.

Keeping your instance of RemoteBusinessLogic alive is obviously important as you found from your testing. So making it an instance variable of your server GUI class makes it more prominent rather than holding on to it as a side effect in a utility class.
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sean Keane wrote:Do you actually create an instance of this class or it is just a utility class with static methods?


It's a utility class with a static method.
 
Sean Keane
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Super. Would you agree that an instance field in an object that is guaranteed to live as long as the server will also solve the problem here? One such object being the server window. Just checking that I am not missing something.
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sean Keane wrote:Would you agree that an instance field in an object that is guaranteed to live as long as the server will also solve the problem here?


If you have a gui window for your server (not everybody uses this approach) you can use an instance in the server window and then the utility class is a good alternative. Also if you want a seperate class with one well-defined purpose (registering your object) you could use the utility class alternative, because you could say it's not the responsibility of your view to register the object. And you could also reuse the utility class in your tests to register the object to test your remote business service implementation.
 
Sean Keane
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So the moral of the story is - keep a reference to the implementation of your remote service so that the reference stays alive for as long as the server is alive.

One option is an instance field in your server, as an instance of the server will always be alive for as long as your server is alive. Another option is to store the reference in a static field of a class that will be loaded as the server is starting up.
 
They gave me pumpkin ice cream. It was not pumpkin pie ice cream. Wiping my tongue on this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic