[JBoss JIRA] (ISPN-7095) JCache remote CacheManger needs to be aware of current server state
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7095?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-7095:
-------------------------------
Description:
As per ISPN-6574 the JCache API needs to reflect correctly on caches created from outside of this API (in server config for example). This issue was addressed for the {{getCache(...)}} method, but remains unfixed for other three methods mentioned in previous request: {{getCacheNames()}}, {{enableManagement(..)}} and {{enableStatistics(...)}}
*Note:* During test creation I found out that invoking CacheManager.getCache will refresh that particular caches reference in the manager and the rest of the methods work correctly afterwards (for that one cache).
was:
As per ISPN-6574 the JCache API needs to reflect correctly on caches created from outside of this API (in server config for example). This issue was addressed for .getCache method, but remains unfixed for other three methods mentioned in previous request.
*Note:* During test creation I found out that invoking CacheManager.getCache will refresh that particular caches reference in the manager and the rest of the methods work correctly afterwards (for that one cache).
> JCache remote CacheManger needs to be aware of current server state
> -------------------------------------------------------------------
>
> Key: ISPN-7095
> URL: https://issues.jboss.org/browse/ISPN-7095
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Affects Versions: 9.0.0.Alpha3
> Reporter: Zdenek Hostasa
>
> As per ISPN-6574 the JCache API needs to reflect correctly on caches created from outside of this API (in server config for example). This issue was addressed for the {{getCache(...)}} method, but remains unfixed for other three methods mentioned in previous request: {{getCacheNames()}}, {{enableManagement(..)}} and {{enableStatistics(...)}}
> *Note:* During test creation I found out that invoking CacheManager.getCache will refresh that particular caches reference in the manager and the rest of the methods work correctly afterwards (for that one cache).
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
7 years, 6 months
[JBoss JIRA] (ISPN-7129) Duplicate cache names shouldn't be allowed
by Jakub Markos (JIRA)
[ https://issues.jboss.org/browse/ISPN-7129?page=com.atlassian.jira.plugin.... ]
Jakub Markos updated ISPN-7129:
-------------------------------
Status: Open (was: New)
> Duplicate cache names shouldn't be allowed
> ------------------------------------------
>
> Key: ISPN-7129
> URL: https://issues.jboss.org/browse/ISPN-7129
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 9.0.0.Alpha2
> Reporter: Jakub Markos
>
> Multiple caches with the same name can be defined without a WARN/ERROR message.
> It's also unclear which one will be used, for example with this configuration
> {code}
> <distributed-cache name="testCache"/>
> <distributed-cache name="testCache">
> <eviction max-entries="100" />
> </distributed-cache>
> <distributed-cache name="testCache"/>
> {code}
> -the cache with eviction will be used.- Actually the configurations are merged...
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
7 years, 6 months
[JBoss JIRA] (ISPN-7129) Duplicate cache names shouldn't be allowed
by Jakub Markos (JIRA)
[ https://issues.jboss.org/browse/ISPN-7129?page=com.atlassian.jira.plugin.... ]
Jakub Markos reassigned ISPN-7129:
----------------------------------
Assignee: Jakub Markos
> Duplicate cache names shouldn't be allowed
> ------------------------------------------
>
> Key: ISPN-7129
> URL: https://issues.jboss.org/browse/ISPN-7129
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 9.0.0.Alpha2
> Reporter: Jakub Markos
> Assignee: Jakub Markos
>
> Multiple caches with the same name can be defined without a WARN/ERROR message.
> It's also unclear which one will be used, for example with this configuration
> {code}
> <distributed-cache name="testCache"/>
> <distributed-cache name="testCache">
> <eviction max-entries="100" />
> </distributed-cache>
> <distributed-cache name="testCache"/>
> {code}
> -the cache with eviction will be used.- Actually the configurations are merged...
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
7 years, 6 months
[JBoss JIRA] (ISPN-7119) Change cluster listener to use JGroups non OOB thread
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-7119?page=com.atlassian.jira.plugin.... ]
William Burns closed ISPN-7119.
-------------------------------
Resolution: Duplicate Issue
Accidentally created twice. Copy of ISPN-7118
> Change cluster listener to use JGroups non OOB thread
> -----------------------------------------------------
>
> Key: ISPN-7119
> URL: https://issues.jboss.org/browse/ISPN-7119
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: William Burns
> Assignee: William Burns
>
> Cluster listeners could use non OOB thread from JGroups instead of distributed executor to enforce ordering. This would allow the primary owner to release the lock earlier by not having to wait for response from the cluster listener nodes.
> This can lose a message though if the primary owner goes down after the originator got the response that the value was written but before the primary owner sent the message to the listeners. Also could have an issue that if state transfer occurs and the primary owner changes while in the same state you could get a new event from the new primary before the previous ones was received causing an ordering issue.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
7 years, 6 months
[JBoss JIRA] (ISPN-6862) HeuristicMixedException in simple failover scenario
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6862?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-6862.
--------------------------------
Resolution: Won't Fix
The log shows that EAP stops the JGroups {{JChannel}} before stopping the Infinispan {{DefaultCacheManager}} that's running on top of it. Infinispan doesn't expect this, and that's why it logs all those {{ISPN000197: Error updating cluster member list:}} messages.
That's also the cause of the {{HeuristicMixedException}}. Normally, Infinispan blocks shutdown until all the local transactions have been committed, but when the underlying channel is already disconnected, there's no way to actually commit the transaction.
> HeuristicMixedException in simple failover scenario
> ---------------------------------------------------
>
> Key: ISPN-6862
> URL: https://issues.jboss.org/browse/ISPN-6862
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.1.4.Final
> Reporter: Bogdan Sikora
>
> https://paste.fedoraproject.org/391436/
> Scenario:
> * 3x Eap as worker, 1x apache core as Balancer
> * Send request to balancer
> * Kill worker that handled request
> * Send request to balancer
> {noformat}
> 2016-07-15 04:51:51,916 ERROR [stderr] (ServerService Thread Pool -- 82) Exception in thread "ServerService Thread Pool -- 82" org.infinispan.commons.CacheException: javax.transaction.HeuristicMixedException
> 2016-07-15 04:51:51,917 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:74)
> 2016-07-15 04:51:51,919 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.CacheRegistry.lambda$close$0(CacheRegistry.java:101)
> 2016-07-15 04:51:51,919 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.CacheRegistry$$Lambda$196.00000000E4013240.run(Unknown Source)
> 2016-07-15 04:51:51,920 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.service.concurrent.StampedLockServiceExecutor.close(StampedLockServiceExecutor.java:55)
> 2016-07-15 04:51:51,921 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.CacheRegistry.close(CacheRegistry.java:94)
> 2016-07-15 04:51:51,921 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 91) WFLYCLINF0003: Stopped routing cache from web container
> 2016-07-15 04:51:51,922 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.CacheRegistryFactory$1.close(CacheRegistryFactory.java:56)
> 2016-07-15 04:51:51,924 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.RegistryBuilder.stop(RegistryBuilder.java:88)
> 2016-07-15 04:51:51,925 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000080: Disconnecting JGroups channel web
> 2016-07-15 04:51:51,926 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.service.AsynchronousServiceBuilder$2.run(AsynchronousServiceBuilder.java:130)
> 2016-07-15 04:51:51,927 ERROR [stderr] (ServerService Thread Pool -- 82) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> 2016-07-15 04:51:51,927 ERROR [stderr] (ServerService Thread Pool -- 82) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 2016-07-15 04:51:51,927 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p12-t6) ISPN000197: Error updating cluster member list: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from jboss-eap-7.0, see cause for remote stack trace
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:764)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$0(JGroupsTransport.java:602)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$169.00000000F91C85F0.apply(Unknown Source)
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:613)
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:588)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:485)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1973)
> at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.futureDone(SingleResponseFuture.java:30)
> at org.jgroups.blocks.Request.checkCompletion(Request.java:151)
> at org.jgroups.blocks.UnicastRequest.transportClosed(UnicastRequest.java:169)
> at org.jgroups.blocks.RequestCorrelator.stop(RequestCorrelator.java:253)
> at org.jgroups.blocks.MessageDispatcher.stop(MessageDispatcher.java:167)
> at org.jgroups.blocks.MessageDispatcher.channelDisconnected(MessageDispatcher.java:537)
> at org.jgroups.Channel.notifyChannelDisconnected(Channel.java:533)
> at org.jgroups.fork.ForkChannel.disconnect(ForkChannel.java:186)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.stop(JGroupsTransport.java:263)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:887)
> at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:692)
> at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:570)
> at org.infinispan.factories.GlobalComponentRegistry.stop(GlobalComponentRegistry.java:263)
> at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:689)
> at org.jboss.as.clustering.infinispan.subsystem.CacheContainerBuilder.stop(CacheContainerBuilder.java:120)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.IllegalStateException: transport was closed
> at org.jgroups.blocks.UnicastRequest.transportClosed(UnicastRequest.java:164)
> ... 22 more
> 2016-07-15 04:51:51,928 ERROR [stderr] (ServerService Thread Pool -- 82) at java.lang.Thread.run(Thread.java:785)
> 2016-07-15 04:51:51,929 ERROR [stderr] (ServerService Thread Pool -- 82) at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 2016-07-15 04:51:51,930 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p12-t6) ISPN000197: Error updating cluster member list: org.infinispan.commons.CacheException: java.lang.IllegalStateException: channel is not connected
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.rethrowAsCacheException(CommandAwareRpcDispatcher.java:132)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:112)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotelyAsync(JGroupsTransport.java:551)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:505)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:465)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:452)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:363)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:650)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener$$Lambda$167.000000009C90CF80.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.runInternal(SemaphoreCompletionService.java:173)
> at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.run(SemaphoreCompletionService.java:151)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at org.jboss.as.clustering.infinispan.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:48)
> at org.jboss.as.clustering.infinispan.ClassLoaderThreadFactory$$Lambda$129.00000000A04F9300.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.IllegalStateException: channel is not connected
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:713)
> at org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:164)
> at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:325)
> at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:76)
> at org.jgroups.blocks.Request.execute(Request.java:66)
> at org.jgroups.blocks.MessageDispatcher.cast(MessageDispatcher.java:363)
> at org.jgroups.blocks.MessageDispatcher.cast(MessageDispatcher.java:376)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processCalls(CommandAwareRpcDispatcher.java:300)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:108)
> ... 15 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (ISPN-4213) clustered Wildfly unexpected nodes SuspectException
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4213?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-4213.
--------------------------------
Fix Version/s: 8.2.2.Final
Resolution: Done
The suspect exceptions should be fixed by ISPN-6599.
> clustered Wildfly unexpected nodes SuspectException
> ---------------------------------------------------
>
> Key: ISPN-4213
> URL: https://issues.jboss.org/browse/ISPN-4213
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.1.Final
> Environment: ubuntu 13.04, jboss wildfly 8.0.1, infinispan 6.0.1.Final, jgroups 3.4.3.Final
> Reporter: Hielke Hoeve
> Fix For: 8.2.2.Final
>
>
> Our current production system has a cluster of 2 nodes using Wildfly 8.0.1. We have used the "ha" profile and "ha" socket-binding-group as a baseline to create the profile for the clusters. The cluster has a REST application deployed. This application uses 2 infinispan cache containers (hibernate and application). In total these views have 5 local caches, 3 invalidation caches and 7 replicated caches. The cache containers use udp as transport. Our hibernate container is the default config as provided by the "ha" profile.
> Last thursday and yesterday the one of the nodes started throwing SuspectException during a hibernate flush. The applications had only a few active users.
> Node 1 says:
> -----------------
> 2014-04-15 17:40:53,380 ERROR [org.jboss.as.ejb3.invocation] (default task-22) JBAS014134: EJB Invocation failed on component ConversatieResourceRESTService
> for method public javax.ws.rs.core.Response ...ConversatieResourceRESTService.setStatus(...event.Con
> versatieStatusObject): javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
> ...
> ...
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32) [infinispan-core-6.0.1.Final.jar:6.0.1.Final]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70) [infinispan-core-6.0.1.Final.jar:6.0.1.Final]
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) [infinispan-core-6.0.1.Final.jar:6.0.1.Final]
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1306) [infinispan-core-6.0.1.Final.jar:6.0.1.Final]
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:878) [infinispan-core-6.0.1.Final.jar:6.0.1.Final]
> at org.infinispan.CacheImpl.put(CacheImpl.java:870) [infinispan-core-6.0.1.Final.jar:6.0.1.Final]
> at org.infinispan.DecoratedCache.put(DecoratedCache.java:401) [infinispan-core-6.0.1.Final.jar:6.0.1.Final]
> at org.infinispan.AbstractDelegatingCache.put(AbstractDelegatingCache.java:276) [infinispan-core-6.0.1.Final.jar:6.0.1.Final]
> at org.hibernate.cache.infinispan.access.TransactionalAccessDelegate.update(TransactionalAccessDelegate.java:192) [hibernate-infinispan-4.3.4.Final.j
> ar:4.3.4.Final]
> at org.hibernate.cache.infinispan.entity.TransactionalAccess.update(TransactionalAccess.java:89) [hibernate-infinispan-4.3.4.Final.jar:4.3.4.Final]
> at org.hibernate.action.internal.EntityUpdateAction.cacheUpdate(EntityUpdateAction.java:234) [hibernate-core-4.3.4.Final.jar:4.3.4.Final]
> at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:209) [hibernate-core-4.3.4.Final.jar:4.3.4.Final]
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:461) [hibernate-core-4.3.4.Final.jar:4.3.4.Final]
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:347) [hibernate-core-4.3.4.Final.jar:4.3.4.Final]
> at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:350) [hibernate-core-4.3.4.Final.j
> ar:4.3.4.Final]
> at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:56) [hibernate-core-4.3.4.Final.jar:4.3.4.Final]
> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) [hibernate-core-4.3.4.Final.jar:4.3.4.Final]
> at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:425) [hibernate-core-4.3.4.Final.jar:4.3.4.Final]
> at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallba
> ckCoordinatorNonTrackingImpl.java:110) [hibernate-core-4.3.4.Final.jar:4.3.4.Final]
> ... 117 more
> Caused by: SuspectedException
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:406)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:353) [infinispan-core-6.0.1.F
> inal.jar:6.0.1.Final]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167) [infinispan-core-6.0.1
> .Final.jar:6.0.1.Final]
> ... 161 more
> 2014-04-15 17:40:53,707 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-7,shared=udp) ISPN000094: Received new cluster view: [node1:rest1-even/hibernate-even|2] (1) [node1:rest1-even/hibernate-even]
> 2014-04-15 17:40:53,707 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-14,shared=udp) ISPN000094: Received new cluster view: [node1:rest1-even/application-even|2] (1) [node1:rest1-even/application-even]
> Node 2 says:
> -----------------
> 2014-04-15 17:40:17,934 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-19,shared=udp) ISPN000094: Received new cluster view: [node2:rest2-even/hibernate-even|2] (1) [node2:rest2-even/hibernate-even]
> 2014-04-15 17:40:17,934 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-17,shared=udp) ISPN000094: Received new cluster view: [node2:rest2-even/application-even|2] (1) [node2:rest2-even/application-even]
> ...
> ...
> 2014-04-15 17:40:50,737 WARN [org.jgroups.protocols.UDP] (Timer-2,shared=udp) JGRP000032: null: no physical address for node1:rest1-even/hibernate-even, dropping message
> 2014-04-15 17:40:52,543 WARN [org.jgroups.protocols.UDP] (Timer-5,shared=udp) JGRP000032: null: no physical address for node1:rest1-even/application-even, dropping message
> (repeats 100 times)
> ...
> Is there any way I can get more logging than the WARNs above? Does anyone have pointers how or when this SuspectException is thrown?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (ISPN-6753) Ignore cache not found on remote when using invalidation caches
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6753?page=com.atlassian.jira.plugin.... ]
Dan Berindei resolved ISPN-6753.
--------------------------------
Resolution: Duplicate Issue
Duplicate of ISPN-6721. Ignoring {{SuspectException}} and {{CacheNotFoundResponse}} should be the default since 8.2.2.Final, so there's no need for a new option.
> Ignore cache not found on remote when using invalidation caches
> ---------------------------------------------------------------
>
> Key: ISPN-6753
> URL: https://issues.jboss.org/browse/ISPN-6753
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 8.2.2.Final
> Reporter: Karl von Randow
>
> We are using Infinispan as a 2LC for Hibernate. Cache regions are dynamically created, named for Hibernate entities. They clone the {{entity}} cache configuration and create new regions. This works great.
> We have a cluster of five application servers, each running the same stack and participating in the invalidation cluster.
> When we roll out a new version across our application servers we sometimes add, remove or rename entities. If we've removed an entity this causes that cache to not exist on the newly updated application server. This causes the other application servers, not yet updated, to try to send invalidation messages to the new one and when they discover that the cache isn't running they throw a {{SuspectException}} and start to fail.
> In {{AbstractTransport}} there is an option to ignore the {{CacheNotFoundResponse}}. That does not appear to be set in my case. I haven't found a configuration option to have this set. With apologies if it is already available: Would it be possible to add an option to ignore the cache not found responses?
> If it is something that should be added I am happy to attempt to supply a PR.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months