[
https://issues.jboss.org/browse/ISPN-1348?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-1348:
----------------------------------------
Converting ClusterIdGenerator into a global component has the opposite side effect which
is, how do HR/Memcached servers get hold of it now when there's no access to global
component registry? This is slightly easier because we can get hold of the global
component registry via LifecycleCallbacks implementation and cache the ClusterIdGenerator
there.
Btw, converting ClusterIdGenerator has a slight impact which is that it's only in use
if tx recovery is enabled, or HR/Memcached servers are in use. At CacheManager startup
time, you know if tx recovery is on or not, but you don't know if HR/Memcached servers
will be in use. So, my current solution always creates a ClusterIdGenerator which is not
good.
It needs some further baking...
Cluster ID generator initialization might not work when default cache
is not clustered
--------------------------------------------------------------------------------------
Key: ISPN-1348
URL:
https://issues.jboss.org/browse/ISPN-1348
Project: Infinispan
Issue Type: Bug
Components: Cache Server
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 5.1.0.ALPHA1
This is related to the changes introduced as part of ISPN-1233. In Hot Rod servers,
cluster ID generator initialization can fail to assign an initial view rank if the default
cache is not clustered but other caches are. A better solution would be to simply cache
the cache manager on construction, and if a new version for a clustered cache is created
and the rank is not set yet (i.e. in cases such as AS7 where cache manager is started
before the servers themselves), use the cached cache manager's transport to quickly
calculate the view rank.
This won't happen with Memcached because you can only interact with the default
cache.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira