[JBoss JIRA] (ISPN-3441) Silence OutdatedTopologyExceptions
by Michal Linhard (JIRA)
[ https://issues.jboss.org/browse/ISPN-3441?page=com.atlassian.jira.plugin.... ]
Michal Linhard commented on ISPN-3441:
--------------------------------------
Still in JDG 6.2.0.ER4
> Silence OutdatedTopologyExceptions
> ----------------------------------
>
> Key: ISPN-3441
> URL: https://issues.jboss.org/browse/ISPN-3441
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 6.0.0.Alpha3, 6.0.0.Final
> Reporter: Michal Linhard
> Assignee: Dan Berindei
> Priority: Minor
>
> from:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/RESILIENCE...
> when crashing one node of four in dist sync (owners=2) config resilience test I get:
> {code}
> 06:47:16,805 ERROR [org.infinispan.remoting.InboundInvocationHandlerImpl] (remote-thread-20) Exception executing command: org.infinispan.statetransfer.OutdatedTopologyException: Cache topology changed while the command was executing: expected 5, got 6
> at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleNonTxWriteCommand(BaseDistributionInterceptor.java:126) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitPutKeyValueCommand(NonTxDistributionInterceptor.java:72) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:292) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:374) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:157) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:47) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:200) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:128) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:32) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:39) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:48) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:97) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:46) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:169) [infinispan-core-6.0.0.Alpha3-redhat-1.jar:6.0.0.Alpha3-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {code}
> Isn't this similar candidate for silencing as SuspectException (ISPN-2577) ?
> The difference here is that it doesn't bubble up to hot rod user.
--
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
11 years, 1 month
[JBoss JIRA] (ISPN-3751) PutFromLoadValidator read stale data from the cache.
by Flemming Harms (JIRA)
Flemming Harms created ISPN-3751:
------------------------------------
Summary: PutFromLoadValidator read stale data from the cache.
Key: ISPN-3751
URL: https://issues.jboss.org/browse/ISPN-3751
Project: Infinispan
Issue Type: Bug
Components: Locking and Concurrency
Affects Versions: 4.2.1.FINAL
Reporter: Flemming Harms
Assignee: Mircea Markus
Hi,
This problem actual started as a investigation on the JBoss Cache in a cluster, but we believe this also exists in Infinispan. We able to reproduce it with Infinispan also. It's a combination of a problem in the Hibernate 2LC and Infinispan so I might not be the right place to create this jira.
This is what we have been able to find out so far. "When an invalidation event arrived on node #2 there is no callback to the 2LC layer that will make sure to call invalidate. Another problem we discover was if a collection is invalidated on node #1 twice in a row the second time no invalidation event is broadcasts to node #2, and that’s a problem because in between invalidation event #1 and #2 the PutFromLoadValidator is called on node #2 and this makes it read stale data from the cache.
The forum link contains a possible patch for Infinispan and Hibernate 2LC, but there might be other areas in the code the patch could introduce a problem for
--
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
11 years, 1 month
[JBoss JIRA] (ISPN-3750) Configuration.toProperties
by Michal Linhard (JIRA)
[ https://issues.jboss.org/browse/ISPN-3750?page=com.atlassian.jira.plugin.... ]
Michal Linhard commented on ISPN-3750:
--------------------------------------
https://github.com/mlinhard/infinispan/tree/t_ispn_3750
> Configuration.toProperties
> --------------------------
>
> Key: ISPN-3750
> URL: https://issues.jboss.org/browse/ISPN-3750
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Affects Versions: 6.0.0.Final
> Reporter: Michal Linhard
> Assignee: Michal Linhard
>
> I'd like to add methods
> Configuration.toProperties() and
> GlobalConfiguration.toProperties()
> that would return current configuration values in flat key value structure (e.g. java.util.Properties) where property keys would reflect names of configuration fields and structure would be reflected by extending the key prefix and dividing by dot. e.g. clustering.hash.numOwners=2
> The least intrusive and maintenance demanding implementation is via Reflection.
> The flat configuration would be exposed via JMX objects, e.g.
> jboss.infinispan:type=Cache,name="testCache(dist_sync)",manager="default",component=Cache
> attribute "configurationProperties"
> jboss.infinispan:type=CacheManager,name="default",component=CacheManager
> attribute "globalConfigurationProperties"
> This is a diagnostic output feature and doesn't affect the way how Infinispan is configured.
--
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
11 years, 1 month
[JBoss JIRA] (ISPN-3750) Configuration.toProperties
by Michal Linhard (JIRA)
Michal Linhard created ISPN-3750:
------------------------------------
Summary: Configuration.toProperties
Key: ISPN-3750
URL: https://issues.jboss.org/browse/ISPN-3750
Project: Infinispan
Issue Type: Feature Request
Components: Configuration
Affects Versions: 6.0.0.Final
Reporter: Michal Linhard
Assignee: Michal Linhard
I'd like to add methods
Configuration.toProperties() and
GlobalConfiguration.toProperties()
that would return current configuration values in flat key value structure (e.g. java.util.Properties) where property keys would reflect names of configuration fields and structure would be reflected by extending the key prefix and dividing by dot. e.g. clustering.hash.numOwners=2
The least intrusive and maintenance demanding implementation is via Reflection.
The flat configuration would be exposed via JMX objects, e.g.
jboss.infinispan:type=Cache,name="testCache(dist_sync)",manager="default",component=Cache
attribute "configurationProperties"
jboss.infinispan:type=CacheManager,name="default",component=CacheManager
attribute "globalConfigurationProperties"
This is a diagnostic output feature and doesn't affect the way how Infinispan is configured.
--
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
11 years, 1 month
[JBoss JIRA] (ISPN-3364) Tests from org.infinispan.atomic package fail with AssertionError
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3364?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3364 started by William Burns.
> Tests from org.infinispan.atomic package fail with AssertionError
> -----------------------------------------------------------------
>
> Key: ISPN-3364
> URL: https://issues.jboss.org/browse/ISPN-3364
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.Alpha1
> Environment: RHEL5_x86, RHEL5_x86_64, RHEL6_x86, RHEL5_x86_64 with IBM JDK7
> Reporter: Vitalii Chepeliuk
> Assignee: William Burns
> Labels: 620
> Attachments: LocalDeltaAwarePassivationTest.log.zip, ReplDeltaAwarePassivationTest.log.zip
>
>
> Following tests fail from org.infinispan.atomic package
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testAtomicMap
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testDeltaAware
> org.infinispan.atomic.LocalDeltaAwarePassivationTest.testFineGrainedAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testAtomicMap2
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testDeltaAware
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testDeltaAware2
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testFineGrainedAtomicMap
> org.infinispan.atomic.ReplDeltaAwarePassivationTest.testFineGrainedAtomicMap2
> Add link on jenkins job https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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
11 years, 1 month
[JBoss JIRA] (ISPN-3749) Revisit JGroups Configuration files
by William Burns (JIRA)
William Burns created ISPN-3749:
-----------------------------------
Summary: Revisit JGroups Configuration files
Key: ISPN-3749
URL: https://issues.jboss.org/browse/ISPN-3749
Project: Infinispan
Issue Type: Bug
Components: Configuration
Affects Versions: 6.0.0.Final
Reporter: William Burns
Assignee: Mircea Markus
Bela mentioned that currently our *-tcp.xml files have UFC defined in them. He no longer has that in his default configuration. We should revisit our configuration files to make sure they are as closely aligned to JGroups as we can.
{quote}
<bela_> I was looking at infinispan master and noticed that the *-tcp.xml configs still have UFC in them
<bela_> This is not something I have in the default configs in JGroups...
<bela_> perhaps this should be changed...
<bela_> pferraro: dberindei wburns ^^^
* rachmatowicz has quit (Quit: Ex-Chat)
<wburns> bela_ I can't say I know why it is still there, other than it has been there for a while
<bela_> ok, perhaps someone can take a look ? The closer the Infinispan configs are to the JGroups configs, the better
<pferraro> bela_: WF's tcp stack does not have UFC
<bela_> ok, good. But Infinispan does have it
{quote}
--
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
11 years, 1 month
[JBoss JIRA] (ISPN-3635) Out of data read after write on node losing ownership
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3635?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3635:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1019742|https://bugzilla.redhat.com/show_bug.cgi?id=1019742] from ON_QA to VERIFIED
> Out of data read after write on node losing ownership
> -----------------------------------------------------
>
> Key: ISPN-3635
> URL: https://issues.jboss.org/browse/ISPN-3635
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, State transfer
> Affects Versions: 5.3.0.Final
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> In a situation where a node is losing ownership of an entry (during a state transfer), when the node does a write (and commits that), the change is propagated only to the new owners, the entry is not written locally. However, when it executes read for this key afterwards, it gets the old value as this is directly retrieved from the data container.
> This bug was observed in transactional mode, but might not be limited to it.
--
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
11 years, 1 month
[JBoss JIRA] (ISPN-924) Support Atomic arithmetic operations in the API
by Daniel Nuss (JIRA)
[ https://issues.jboss.org/browse/ISPN-924?page=com.atlassian.jira.plugin.s... ]
Daniel Nuss commented on ISPN-924:
----------------------------------
Is there any chance that this will be implemented in near future? It would be a feature which certainly would be used by my company. At the moment, i implement a cluster-wide counter with the help of hard locks, i think your version will surely perform better.
> Support Atomic arithmetic operations in the API
> -----------------------------------------------
>
> Key: ISPN-924
> URL: https://issues.jboss.org/browse/ISPN-924
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API
> Reporter: Erik Salter
> Assignee: Manik Surtani
>
> It would be useful if Infinispan supported cluster-wide atomic operations for java.lang.Number types in the API -- similar to the AtomicX API in Java.
> Right now, to cobble this functionality, we'd need to do something like:
> - Start a tx
> - Single-lock a key
> - Get and increment
> - Commit
> - And, of course, handle the cache exceptions =)
--
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
11 years, 1 month