[
http://jira.jboss.com/jira/browse/JBAS-4615?page=all ]
Brian Stansberry reopened JBAS-4615:
------------------------------------
Reopening as the current solution only works if the last exception caught by HARMIClient
is NoSuchObjectException. Other recoverable exceptions like ConnectException don't
flush the weak cache without propagating to the client.
NamingContext caches stale Naming stub
--------------------------------------
Key: JBAS-4615
URL:
http://jira.jboss.com/jira/browse/JBAS-4615
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Naming
Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2,
JBossAS-4.2.0.GA
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-5.0.0.Beta3
As an important performance optimization, org.jnp.interfaces.NamingContext statically
caches a WeakReference to the "proxy" to the server-side Naming service. In
most cases this is either an RMI stub (non-HA naming service) or a proxy based on an
HARMIClient (for HA-JNDI). Either way, the cached object uses RMI to communicate with the
server.
This object becomes invalid if the server (non-HA case) or cluster (HA case) it was
associated with is restarted. The object in the restarted server-side RMI runtime will no
longer match the client-side RMI stub, and an invocation over the stub will result in a
java.rmi.NoSuchObjectException on the client. NamingContext's caching of the RMI
greatly increases the odds of this occuring. If this occurs, the cache will be flushed
and the next call will acquire a fresh stub from the server, but the client will get an
exception on the first call.
Proposed solution is discussed on forum thread.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira