HANamingService IllegalStateException: Must call setClustere

[starksm64]

As I'm testing moving the beans from conf/jboss-service.xml to deploy, and I'm now seeing this exception when the HANamingService is starting:

21:01:30,619 INFO [HANamingService] Started HAJNDI bootstrap; jnpPort=1100, backlog=50, bindAddress=/127.0.0.1
21:01:30,623 INFO [DetachedHANamingService$AutomaticDiscovery] Listening on /127.0.0.1:1102, group=230.0.0.4, HA-JNDI address=127.0.0.1:1100
21:01:30,632 ERROR [AbstractKernelController] Error installing to Start: name=HAJNDI state=Create
java.lang.IllegalStateException: Must call setClusteredCache before starting
 at org.jboss.ha.jndi.impl.jbc.JBossCacheDistributedTreeManager.init(JBossCacheDistributedTreeManager.java:128)
 at org.jboss.ha.jndi.HAJNDI.init(HAJNDI.java:89)
 at org.jboss.ha.jndi.DetachedHANamingService.startService(DetachedHANamingService.java:376)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
 at org.jboss.system.ServiceMBeanSupport.pojoStart(ServiceMBeanSupport.java:216)

I don't see how the bean move would be causing this.

[starksm64]

Looking at the JBossCacheDistributedTreeManager that is throwing the exception, it is saying that it needs its HAStub property set, but this is not in the hajndi-jboss-beans.xml config:

 <!-- Handler for the replicated tree -->
 <property name="distributedTreeManager">
 <bean class="org.jboss.ha.jndi.impl.jbc.JBossCacheDistributedTreeManager">
 <property name="clusteredCache"><inject bean="HAPartitionCacheHandler" property="cache"/></property>
 </bean>
 </property>

I see the DetachedHANamingService has called setHAStub as part of its startService. It looks like the change to an mcbean for the naming service has broken the lookup of the Naming proxy, although I don't see a related error.

[starksm64]

Whoops, wrong, its the clusteredCache which is being injected. I guess the HAPartitionCacheHandler has a need to depend on the Naming service as well?

[starksm64]

That's not it as that bean is really controlled by the DistributedStateImpl. Adding a naming dependency to it also does not solve the problem. Still trying to navigate the dependency graph to figure out what is not being initialized. Seems like there should be some error prior to this.

[starksm64]

Ok, so the dependencies just seem broken/unresolvable and I'm not sure why this would work in general. The problem I see is that:

HAJNDI injects JBossCacheDistributedTreeManager.cache which is injected from HAPartitionCacheHandler.cache

HAPartitionCacheHandler another bean, either DistributedState or HAPartition to initialize its cache by calling acquireCache(), but HAPartitionCacheHandler cannot depend on these because they depend on HAPartitionCacheHandler in order to call methods on it!

What is happening right now is that the JBossCacheDistributedTreeManager.clusteredCache property is being injected from the HAPartitionCacheHandler bean cache property, but the cache property has not been set. The mc is assuming that since the HAPartitionCacheHandler is started, its properties are valid. This is not the case. Adding a dependency to the JBossCacheDistributedTreeManager on HAPartition is not changing when the clusteredCache property is set.

The HAPartitionCacheHandler does not appear to be a valid bean in terms of dependency injection. I'm curious how this works before my reorg of deployments.

[starksm64]

I created JBAS-6083 for this issue.

[brian.stansberry]

OK, I'll have a look today and sort this out.

[brian.stansberry]

Looks like the issue here is JBossCacheDistributedTreeManager should have the HAPartitionCacheHandler injected instead of its cache property. It can then call acquireCache() during the start phase of the HANamingService. The current code works if HAPartition goes through start() before JBossCacheDistributedTreeManager is constructed/has properties injected, which is of course too fragile. I'm assuming your move of stuff out of conf/jboss-service.xml has altered the order in which things occur by allowing a bunch of beans to go through construction/property injection while waiting to go through create/start until the naming service dependency is subsequently satisfied.

This is all a hack to speed startup by allowing HAPartition to start a cache and HAPartition's own core channel in parallel. I've been sorely tempted to make the whole issue go away by reverting DistributedState and HA-JNDI to not use JBoss Cache. Using JBC for these adds a lot of conceptual ugliness for what seems like little benefit.

That's a fairly substantial effort though, so I'll just get the dependencies correct this morning.

[starksm64]

Using a demand with state Configured on HAPartition as Ales suggested does resolve the issue:

...
 <!-- Handler for the replicated tree -->
 <property name="distributedTreeManager">
 <bean class="org.jboss.ha.jndi.impl.jbc.JBossCacheDistributedTreeManager">
 <property name="clusteredCache"><inject bean="HAPartitionCacheHandle
r" property="cache"/></property>
 <demand state="Configured">HAPartition</demand>
 </bean>
 </property>

[brian.stansberry]

Good to know. That will allow you to proceed.

I'll get a code fix as I described up w/in an hour; as soon as tests run.

[brian.stansberry]

This is done.