[jboss-dev-forums] [Design of the JBoss EJB Container] - jndi lookup during restart

It seems this is the best forum place to discuss the naming issue. Here is the original forum thread that leads to this: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=114200 and there are couple of user forums that reported this issue as well. E.g., http://www.jboss.com/index.html?module=bb&op=viewtopic&t=96087 and http://www.jboss.com/index.html?module=bb&op=viewtopic&t=65304 Basically, in NamingContext, we use a WeakReferenceMap to cache the jndi server stub information.on the client side. So during a server restart, unless the reference has been gc-ed (e.g., if -Dsun.rmi.dgc.client.gcInterval is defaulted to 60 seconds and server restart takes longer than that time), another client request (e.g., ic.lookup(name)) will result in an exception: java.rmi.NoSuchObjectException: no such object in table Here is a simple code snippet to reproduce it: | while (isTrue) | { | try | { | Context naming = new InitialContext (); | home = (TestSLSBHome)naming.lookup ("TestSLSB"); | | gd = home.create (); | boolean succeed = false; | succeed = gd.isSuccessful(); | System.out.println("The call is successful: " + succeed); | | try | { | // Manual pause here | System.out.println("Please hit enter to continue"); | System.in.read(); | } | catch (Exception ignored) { | } | | } | catch(Exception e) | { | System.out.println("**** Exception happened ...."); | } | So this is obviously a flaw since we can't depend on the dgc to recycle the server stub. A proper way that I propose is to specifically catch the NoSuchObjectException in the lookup() code. When we encounter such an exception, we would flush out the server from the cache and do a fresh lookup again. It should be a simple fix that won't impact the code base. Please note that this fix won't cover the case when the home stub is cached by the application (that is, no jndi lookup every time). It'd still generate the error but in this case, we can use the RetryInterceptor to catch the error and retry. This would already be the case for the clustering call (i.e., SingleRetryInterceptor). Any suggestion? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4073831#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...