[JBoss JIRA] (ISPN-2483) State transfer issue with the transactions for which the originator has crashed
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2483?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2483:
--------------------------------
Priority: Blocker (was: Critical)
> State transfer issue with the transactions for which the originator has crashed
> -------------------------------------------------------------------------------
>
> Key: ISPN-2483
> URL: https://issues.jboss.org/browse/ISPN-2483
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer, Transactions
> Affects Versions: 5.1.8.Final, 5.2.0.Beta3
> Reporter: Mircea Markus
> Assignee: Dan Berindei
> Priority: Blocker
> Fix For: 5.2.0.Final
>
>
> State transfer migrates and prepares the transactions for which the originator has left. On the receiving node, this results in the transaction being prepared and acquiring backup locks which are never released (unless manual intervention).
> This should behave as follows:
> - if there's no recovery enabled, the state producer should not send such transactions but drop them
> - if recovery is enabled these transactions should be sent across. They shouldn't be prepared/acquire backup locks, but be placed in the recovery cache (see RecoveryManagerImpl.inDoubtTransactions)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (ISPN-2439) Deadlock in Map/Reduce tasks
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2439?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2439:
--------------------------------
Priority: Blocker (was: Critical)
> Deadlock in Map/Reduce tasks
> ----------------------------
>
> Key: ISPN-2439
> URL: https://issues.jboss.org/browse/ISPN-2439
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Execution and Map/Reduce
> Affects Versions: 5.2.0.Beta2
> Reporter: Dan Berindei
> Assignee: Mircea Markus
> Priority: Blocker
> Fix For: 5.2.0.Final
>
> Attachments: dfnmrt.log.gz
>
>
> It looks like the Map/Reduce intermediate caches use pessimistic transactions, but the transactions are not guaranteed to write to the keys in the same order. So it's possible for two tasks to get into a deadlock, ending with a TimeoutException:
> {noformat}
> 16:18:40,649 ERROR (testng-DistributedFourNodesMapReduceTest:) [UnitTestTestNGListener] Test testCombinerDoesNotChangeResult(org.infinispan.distexec.mapreduce.DistributedFourNodesMapReduceTest) failed.
> org.infinispan.CacheException: Could not invoke map phase of MapReduce task on remote nodes
> at org.infinispan.distexec.mapreduce.MapReduceTask.invokeEverywhere(MapReduceTask.java:562)
> at org.infinispan.distexec.mapreduce.MapReduceTask.executeMapPhase(MapReduceTask.java:374)
> at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:315)
> at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.testCombinerDoesNotChangeResult(BaseWordCountMapReduceTest.java:188)
> ...
> Caused by: org.infinispan.CacheException: org.infinispan.CacheException: Could not move intermediate keys/values for M/R task 04244b4b-08b1-4fc4-9755-ed02f3f35a3a
> at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.mapAndCombineForDistributedReduction(MapReduceManagerImpl.java:97)
> at org.infinispan.commands.read.MapCombineCommand.perform(MapCombineCommand.java:89)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:110)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:82)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:244)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:217)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
> ...
> Caused by: org.infinispan.CacheException: Could not move intermediate keys/values for M/R task 04244b4b-08b1-4fc4-9755-ed02f3f35a3a
> at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.combine(MapReduceManagerImpl.java:281)
> at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.mapAndCombineForDistributedReduction(MapReduceManagerImpl.java:95)
> ... 26 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [10 seconds] on key [JBoss] for requestor [GlobalTransaction:<NodeD-56763>:10429:remote]! Lock held by [GlobalTransaction:<NodeB-55590>:10432:remote]
> at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:217)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:190)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:190)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:125)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:248)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:131)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:177)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:131)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:125)
> at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:174)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:131)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:212)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:187)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:131)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:131)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:129)
> at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:98)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:131)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:347)
> at org.infinispan.commands.control.LockControlCommand.perform(LockControlCommand.java:150)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:110)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:82)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:244)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:217)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
> ...
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (ISPN-2578) Two PrepareCommands in parallel cause ConcurrentModificationException
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2578?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2578:
--------------------------------
Priority: Blocker (was: Critical)
> Two PrepareCommands in parallel cause ConcurrentModificationException
> ---------------------------------------------------------------------
>
> Key: ISPN-2578
> URL: https://issues.jboss.org/browse/ISPN-2578
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.Beta5
> Reporter: Radim Vansa
> Assignee: Adrian Nistor
> Priority: Blocker
> Fix For: 5.2.0.CR2
>
>
> Situation:
> 1) Node A broadcasts PrepareCommand to nodes B, C
> 2) Node A leaves cluster, causing new topology to be installed
> 3) The command arrives to B and C, with lower topology than the current one
> 4) Both B and C forward the command to node D
> 5) D executes the two commands in parallel and finds out that A has left, therefore executing RollbackCommand
> In {{AbstractTxLockingInterceptor.visitRollbackCommand}} we call {{LockManagerImpl.unlockAll}} which iterates over the keys and unlocks them. As these two prepares aren't synchronized over the {{lockedKeys}} set, one may unlock and remove these keys while the other is iterating through them, causing {{ConcurrentModificationException}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (ISPN-2588) Lock leak during state transfer (causing StaleLocksTransactionTest to fail)
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2588?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2588:
--------------------------------
Assignee: Adrian Nistor (was: Dan Berindei)
> Lock leak during state transfer (causing StaleLocksTransactionTest to fail)
> ---------------------------------------------------------------------------
>
> Key: ISPN-2588
> URL: https://issues.jboss.org/browse/ISPN-2588
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta5
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Priority: Blocker
> Fix For: 5.2.0.Final
>
> Attachments: StaleLocksTransactionTest.zip
>
>
> numOwners=1, pessimistic cache (same applies if A is the only node in cluster)
> 1. tx1 running on A with writes on k, lockOwner(k) == {A}
> 2. A.tx1.lock(k), this doesn't go remotely, and control returns in the InterceptorStack
> 3. at this point B is started and lockOwner(k) == {B}
> 4. the StateTransferInterceptor forwards the command to B which acquires the lock locally
> 5. this is followed by a tx.commit/rollback that would not send the message to B, so the lock on B is pending.
> The logic which determines whether the message to be sent remotely or not is in DistributionInterceptor.visitCommitCommand, which invokes:
> {code:java}
> protected boolean shouldInvokeRemoteTxCommand(TxInvocationContext ctx) {
> return ctx.isOriginLocal() && (ctx.hasModifications() ||
> !((LocalTxInvocationContext) ctx).getRemoteLocksAcquired().isEmpty());
> }
> {code}
> The problem here is that, when forwarding, we don't register the remote node as a locked.I think a more generic solution would also work, e.g. if the viewId of the tx is different from the viewId of the cluster at commit time, always go remotely.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (ISPN-2588) Lock leak during state transfer (causing StaleLocksTransactionTest to fail)
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2588?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2588:
-------------------------------------
Assigned to [~anistor] - please check and close this one once ISPN-2405 is fixed.
> Lock leak during state transfer (causing StaleLocksTransactionTest to fail)
> ---------------------------------------------------------------------------
>
> Key: ISPN-2588
> URL: https://issues.jboss.org/browse/ISPN-2588
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta5
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Priority: Blocker
> Fix For: 5.2.0.Final
>
> Attachments: StaleLocksTransactionTest.zip
>
>
> numOwners=1, pessimistic cache (same applies if A is the only node in cluster)
> 1. tx1 running on A with writes on k, lockOwner(k) == {A}
> 2. A.tx1.lock(k), this doesn't go remotely, and control returns in the InterceptorStack
> 3. at this point B is started and lockOwner(k) == {B}
> 4. the StateTransferInterceptor forwards the command to B which acquires the lock locally
> 5. this is followed by a tx.commit/rollback that would not send the message to B, so the lock on B is pending.
> The logic which determines whether the message to be sent remotely or not is in DistributionInterceptor.visitCommitCommand, which invokes:
> {code:java}
> protected boolean shouldInvokeRemoteTxCommand(TxInvocationContext ctx) {
> return ctx.isOriginLocal() && (ctx.hasModifications() ||
> !((LocalTxInvocationContext) ctx).getRemoteLocksAcquired().isEmpty());
> }
> {code}
> The problem here is that, when forwarding, we don't register the remote node as a locked.I think a more generic solution would also work, e.g. if the viewId of the tx is different from the viewId of the cluster at commit time, always go remotely.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (ISPN-2588) Lock leak during state transfer (causing StaleLocksTransactionTest to fail)
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2588?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2588:
--------------------------------
Priority: Blocker (was: Critical)
> Lock leak during state transfer (causing StaleLocksTransactionTest to fail)
> ---------------------------------------------------------------------------
>
> Key: ISPN-2588
> URL: https://issues.jboss.org/browse/ISPN-2588
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta5
> Reporter: Mircea Markus
> Assignee: Dan Berindei
> Priority: Blocker
> Fix For: 5.2.0.Final
>
> Attachments: StaleLocksTransactionTest.zip
>
>
> numOwners=1, pessimistic cache (same applies if A is the only node in cluster)
> 1. tx1 running on A with writes on k, lockOwner(k) == {A}
> 2. A.tx1.lock(k), this doesn't go remotely, and control returns in the InterceptorStack
> 3. at this point B is started and lockOwner(k) == {B}
> 4. the StateTransferInterceptor forwards the command to B which acquires the lock locally
> 5. this is followed by a tx.commit/rollback that would not send the message to B, so the lock on B is pending.
> The logic which determines whether the message to be sent remotely or not is in DistributionInterceptor.visitCommitCommand, which invokes:
> {code:java}
> protected boolean shouldInvokeRemoteTxCommand(TxInvocationContext ctx) {
> return ctx.isOriginLocal() && (ctx.hasModifications() ||
> !((LocalTxInvocationContext) ctx).getRemoteLocksAcquired().isEmpty());
> }
> {code}
> The problem here is that, when forwarding, we don't register the remote node as a locked.I think a more generic solution would also work, e.g. if the viewId of the tx is different from the viewId of the cluster at commit time, always go remotely.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (ISPN-2633) IllegalArgumentException: Address shall not be null and broken views upon JOIN
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2633?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2633:
--------------------------------
Fix Version/s: 5.3.0.Final
(was: 5.2.0.Final)
> IllegalArgumentException: Address shall not be null and broken views upon JOIN
> ------------------------------------------------------------------------------
>
> Key: ISPN-2633
> URL: https://issues.jboss.org/browse/ISPN-2633
> Project: Infinispan
> Issue Type: Bug
> Environment: Windows 2008
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 5.3.0.Final
>
> Attachments: configs.zip, serverlogs.zip
>
>
> Running our AS testsuite with master (which includes fix for ISPN-2572) I am instead seeing the following.
> The same node is present twice in the view, looks like something is wrong with JOINs as this happen upon joins.
> {noformat}
> 15:51:41,376 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (OOB-20,null) dropping unicast message to wrong destination node-1/ejb; my local_addr is node-1/ejb
> 15:51:41,821 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 19) ISPN000094: Received new cluster view: [node-0/ejb|12] [node-0/ejb, node-1/ejb, node-1/ejb]
> 15:51:41,825 WARN [org.jgroups.protocols.TCP] (FD_SOCK pinger,ejb,node-1/ejb) null: logical address cache didn't contain all physical address, sending up a discovery request
> 15:51:41,825 ERROR [org.jgroups.protocols.TCP] (FD_SOCK pinger,ejb,node-1/ejb) failed sending message to cluster (69 bytes): java.lang.NullPointerException, cause: null
> 15:51:42,185 ERROR [org.jgroups.JChannel] (ServerService Thread Pool -- 19) exception in channelConnected() callback: java.lang.IllegalStateException: JBAS010272: A node named node-1 already exists in this cluster. Perhaps there is already a server running on this host? If so, restart this server with a unique node name, via -Djboss.node.name=<node-name>
> at org.jboss.as.clustering.jgroups.subsystem.ChannelService.channelConnected(ChannelService.java:105)
> at org.jgroups.Channel.notifyChannelConnected(Channel.java:495)
> at org.jgroups.JChannel.connect(JChannel.java:286)
> at org.jgroups.JChannel.connect(JChannel.java:268)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:207)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:198)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_32]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_32]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_32]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_32]
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:883)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:654)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:643)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:546)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:225)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:681)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:653)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:549)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:563)
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:107)
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:98)
> at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:82)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_32]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_32]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
> 15:51:42,204 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 19) MSC00001: Failed to start service jboss.infinispan.ejb.remote-connector-client-mappings: org.jboss.msc.service.StartException in service jboss.infinispan.ejb.remote-connector-client-mappings: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:87)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_32]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_32]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
> Caused by: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:247)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:681)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:653)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:549)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:563)
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:107)
> at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:98)
> at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:82)
> ... 4 more
> Caused by: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:883)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:654)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:643)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:546)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:225)
> ... 12 more
> Caused by: java.lang.IllegalArgumentException: Address shall not be null
> at org.infinispan.remoting.transport.jgroups.JGroupsAddress.<init>(JGroupsAddress.java:48)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.fromJGroupsAddress(JGroupsTransport.java:686)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:227)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:198)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_32]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_32]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_32]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_32]
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
> ... 17 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months