问题描述
我正在使用Infinispan 7.2.3开发Wildfly 9.
I'm working on Wildfly 9 with Infinispan 7.2.3.
我正面临一个与分布式缓存有关的奇怪问题:
I'm facing up to a strange problem related to distributed cache:
- 在应用程序服务器上，我部署了N次公开REST服务的战争
- 每个服务代码都有共同的职责来检查JNDI上是否已经存在CacheManager si，如果是，它将使用它，否则我将创建一个新的并将其绑定到JNDI.因此，每次战争都使用唯一的CacheManager实例.
- Infinispan CacheManager以分布式模式配置.
infinispan和jgroups是从应用程序服务器提供的.经过所有战争的重新部署操作(部署和部署)后，如果我突然开始向这些服务发送REST请求，则会收到此错误:
The infinispan and jgroups are provided from the application server.After a re-deploy operation (undploy and deploy) of all the wars if i suddenly start to send REST request to these services i get this error:
18:23:42,366 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p2-t12) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.Timeout
Exception: Replication timeout for ws-7-aor-58034
at org.infinispan.remoting.transport.AbstractTransport.parseResponseAndAddToResponseList(AbstractTransport.java:87)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:586)
at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:402)
at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:393)
at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:309)
at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener$1.run(ClusterTopologyManagerImpl.java:590)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
18:23:42,539 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (remote-thread--p11-t2) ISPN000329: Unable to read rebalancing status from coordinator ws-7-aor-19211: org.infinispan.util.concurrent.TimeoutException: Node ws-7-aor-19211 timed out
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:248)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:561)
at org.infinispan.topology.ClusterTopologyManagerImpl.fetchRebalancingStatusFromCoordinator(ClusterTopologyManagerImpl.java:129)
at org.infinispan.topology.ClusterTopologyManagerImpl.start(ClusterTopologyManagerImpl.java:118)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:207)
at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
at org.infinispan.factories.AbstractComponentRegistry.wireDependencies(AbstractComponentRegistry.java:132)
at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler$2.run(GlobalInboundInvocationHandler.java:156)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.jgroups.TimeoutException: timeout waiting for response from ws-7-aor-19211, request: org.jgroups.blocks.UnicastRequest@75770aa6, req_id=6, mode=GET_ALL, target=ws-7-aor-19211
at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:427)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:433)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:241)
... 19 more
这是cachemanager的初始化代码:
This is the initalization code for cachemanager:
try {
ctx = new InitialContext();
cacheManager = (DefaultCacheManager)ctx.lookup(SessionConstants.CACHE_MANAGER_GLOBAL_JNDI_NAME);
} catch (NamingException e1) {
logger.error("SessionHooverJob not able to find: java:global/klopotekCacheManager ... a new instance will be created!");
}
if (cacheManager ==null){
...
configurator = ConfiguratorFactory.getStackConfigurator("default-configs/default-jgroups-udp.xml");
ProtocolConfiguration udpConfiguration = configurator.getProtocolStack().get(0);
if ("UDP".equalsIgnoreCase(udpConfiguration.getProtocolName()) && mcastAddr != null){
udpConfiguration.getProperties().put("mcast_addr", mcastAddr);
}
GlobalConfigurationBuilder gcb = new GlobalConfigurationBuilder();
gcb.globalJmxStatistics().enabled(true).allowDuplicateDomains(true);
gcb.transport().defaultTransport()
.addProperty(JGroupsTransport.CONFIGURATION_STRING, configurator.getProtocolStackString());
//.addProperty(JGroupsTransport.CONFIGURATION_FILE, "config/jgroups.xml");
ConfigurationBuilder builder = new ConfigurationBuilder();
builder.clustering().cacheMode(CacheMode.DIST_SYNC).expiration().lifespan(24l, TimeUnit.HOURS);;
cacheManager = new DefaultCacheManager(gcb.build(),
builder.build());
如果在部署后经过40-60秒左右的时间，则不会发生此问题.如果我有1个JNDI会话管理器已经建立了jgroups通道，即使我取消部署所有战争……为什么jgroups会再次尝试进行重新平衡?
The problem doesn't occur if a time of around 40-60 seconds passes after deploying.If i have 1 JNDI session manager which have built the jgroups channel, even if i undeploy the all the war... why jgroups try to do rebalance again?
是否需要设置一些配置属性?
Is there some configuration property to set?
推荐答案
只要知道服务器管理的Infinispan资源的生命周期要求/约束，即使使用JNDI，使用WildFly的Infinispan子系统的缓存也没有问题. .在WildFly中，所有Infinispan资源都是按需创建/启动的，包括缓存管理器，缓存配置和缓存.如果没有服务需要给定的Infinispan资源，则不会启动它(也不绑定到JNDI).同样，当不再有服务需要给定的Infinispan资源时，该服务将停止(并删除其JNDI绑定).因此，为了通过JNDI查找Infinispan资源，必须首先强制其启动.最简单的方法是创建资源引用(即resource-ref或resource-env-ref).例如
There's nothing wrong with using the caches from WildFly's Infinispan subsystem, even via JNDI, so long as you are aware of the lifecycle requirements/constraints of server managed Infinispan resources. In WildFly, all Infinispan resources are created/started on demand, including cache managers, cache configurations, and caches. If no service requires a given Infinispan resource, it is not started (nor is it bound to JNDI). Likewise, when no service any longer requires a given Infinispan resource, it is stopped (and its JNDI binding removed). Thus, in order to lookup an Infinispan resource via JNDI, you must first force it to start.The easiest way to do this is to create a resource reference (i.e. a resource-ref or resource-env-ref).e.g.
<resource-ref>
<res-ref-name>infinispan/mycontainer</res-ref-name>
<lookup-name>java:jboss/infinispan/container/mycontainer</lookup-name>
</resource-ref>
您现在可以在应用程序jndi命名空间中查找缓存管理器.例如
You can now lookup the cache manager in your application jndi namespace.e.g.
Context ctx = new InitialContext();
EmbeddedCacheManager manager = (EmbeddedCacheManager) ctx.lookup("java:comp/env/infinispan/mycontainer");
缓存管理器将已经启动.另外，您永远不要尝试停止服务器管理的缓存管理器.此外，您不能保证安装了在Infinispan子系统中为此容器定义的任何缓存配置.因此，使用getCache("...")方法不是获得对服务器管理的高速缓存的引用的可靠方法.如果要依赖子系统中定义的特定缓存，则可以为缓存本身创建资源引用.例如
The cache manager will already be started. Also, you should never attempt to stop a server managed cache manager. Additionally, you cannot guarantee that any of the cache configurations that are defined within the Infinispan subsystem for this container are installed. Thus, the use of getCache("...") methods are not a reliable way of obtaining a reference to a server managed cache. If you want to depend on a specific cache as defined in the subsystem, you would create a resource reference for the cache itself.e.g.
<resource-ref>
<res-ref-name>infinispan/mycache</res-ref-name>
<lookup-name>java:jboss/infinispan/cache/mycontainer/mycache</lookup-name>
</resource-ref>
您现在可以直接查找缓存.
You can now lookup the cache directly.
Cache<?, ?> cache = (Cache) ctx.lookup("java:comp/env/infinispan/mycache");
缓存将已经启动.同样，您不应尝试停止服务器托管的缓存.取消部署应用程序或关闭服务器时，它将自动停止.
The cache will already be started. Likewise, you should not attempt to stop a server managed cache. It will stop automatically when you application is undeployed or the server is shutdown.
这篇关于Infinispan Jgroups在战争部署后崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！