[jboss-jira] [JBoss JIRA] Commented: (JBAS-7522) JBossCacheManager obtains Cache reference prematurely

[Brian Stansberry (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBAS-7522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12498505#action_12498505 ] 

Brian Stansberry commented on JBAS-7522:
----------------------------------------

Re: "(Need to investigate if that can be avoided.)" in description. Reason this occurs is because the war used in the failing tests includes a context.xml with a <Manager/> element, as does the default context.xml.  In this situation, the JBossContextConfig behavior of replacing the default context.xml-specified Manager instance with one specified by the war's is valid.

The war includes a context.xml in order to configure the Manager's processExpiresFrequency.

> JBossCacheManager obtains Cache reference prematurely
> -----------------------------------------------------
>
>                 Key: JBAS-7522
>                 URL: https://jira.jboss.org/jira/browse/JBAS-7522
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Web (Tomcat) service
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-6.0.0.M2
>
>
> JBossCacheManager ends up acquiring a reference to the JBC cache during it's init method. This is done to allow throwing of ClusteringNotSupportedException by that method, allowing the behavior whereby a the deployment of a <distributable/> webapp in the default config can detect the absence of clustering classes and fall back on the non-clustered StandardManager.
> The problem here is JBossContextConfig can end up creating > 1 JBossCacheManager instance and calling init on it. (Need to investigate if that can be avoided.) If a 2nd instance is created, stop is not called on the first (since it's never been started).  But the cache has been obtained from the CacheManager, increasing the reference count for the cache. Effect is the cache never gets fully released.
> This is the cause of recent failures in trunk of (AttributeBased)SessionPassivationUnitTestCase.
> We don't need to actually obtain the cache reference in init() to detect whether needed classes are available. Just a ref to the CacheManager is sufficient. Defer obtaining the cache reference until start().
> This problem doesn't affect any released code; it's an effect of the work on JBAS-7473.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira