[jboss-jira] [JBoss JIRA] Updated: (JBAS-4622) Can't flush bad naming stub if no java.naming.provider.url specified

[Brian Stansberry (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBAS-4622?page=all ]

Brian Stansberry updated JBAS-4622:
-----------------------------------

    Fix Version/s: JBossAS-4.2.2.GA

> Can't flush bad naming stub if no java.naming.provider.url specified
> --------------------------------------------------------------------
>
>                 Key: JBAS-4622
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4622
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, 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, JBossAS-4.2.2.GA
>
>
> The NamingContext class maintains a static cache of server-side naming stubs, keyed by the address:port of the server.  Entries from this cache are meant to be removed if an IOException is caught when invoking on the stub, thus ensuring that problem stubs are discarded and a new stub lookup is forced.
> This cache clearing process breaks if java.naming.provider.url is not set.  The clearing algorithm is in NamingContext.removeServer(Hashtable) is a no-op if the naming environment does not include java.naming.provider.url.  Based on a comment on the method, the reasoning behind this is to avoid flushing the "local" (i.e. in-vm) server from the cache.  But, the way the naming acquisition process works, a direct ref to the in-vm server will never be stored in the cache anyway, so this distinction in not valid.

-- 
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