October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3552) HotRod Rolling Upgrades NPE when disabling cache store on target node

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3552?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3552: -------------------------------- Fix Version/s: 6.0.0.CR2 > HotRod Rolling Upgrades NPE when disabling cache store on target node > --------------------------------------------------------------------- > > Key: ISPN-3552 > URL: https://issues.jboss.org/browse/ISPN-3552 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Beta1 > Reporter: Tomas Sykora > Assignee: Pedro Ruivo > Labels: jdg62GAblocker > Fix For: 6.0.0.CR2 > > Attachments: standalone-source-node-rollups52-dist.xml, standalone-target-node-rollups-dist.xml > > > After Tristan's fix for https://issues.jboss.org/browse/ISPN-3183 we can move successfully through recordKnownGlobalKeyset and synchronizeData operations. > However, when we want to issue disconnectSource operation on target node, it is failing with given error: > javax.management.MBeanException > at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:273) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:527) > at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:263) > at org.jboss.remotingjmx.protocol.v1.ServerProxy$InvokeHandler.handle(ServerProxy.java:1058) > at org.jboss.remotingjmx.protocol.v1.ServerProxy$MessageReciever$1.run(ServerProxy.java:225) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > Caused by: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:271) > ... 9 more > Caused by: java.lang.NullPointerException > at org.infinispan.persistence.manager.PersistenceManagerImpl.disableStore(PersistenceManagerImpl.java:253) > at org.infinispan.persistence.remote.upgrade.HotRodTargetMigrator.disconnectSource(HotRodTargetMigrator.java:101) > at org.infinispan.upgrade.RollingUpgradeManager.disconnectSource(RollingUpgradeManager.java:71) > ... 14 more > Short input from Tristan: "problem is that after removing the store, it determines there are no more stores left so it tries to remove the loader/writer interceptors which for some reason are missing" > -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2971) AsyncStoreStressTest is broken

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2971?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2971: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > AsyncStoreStressTest is broken > ------------------------------ > > Key: ISPN-2971 > URL: https://issues.jboss.org/browse/ISPN-2971 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.5.Final > Reporter: Adrian Nistor > Assignee: Galder Zamarreño > Priority: Minor > Labels: testsuite_stability > > This test is not run during normal test suite, but we still need to fix this failure and the leaked threads (see System.exit(0) in main method): > {code} > testReadWriteRemove(org.infinispan.stress.AsyncStoreStressTest) Time elapsed: 72.377 sec <<< FAILURE! > java.lang.UnsupportedOperationException > at java.util.AbstractMap$SimpleImmutableEntry.setValue(AbstractMap.java:726) > at org.infinispan.stress.AsyncStoreStressTest.testReadWriteRemove(AsyncStoreStressTest.java:140) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:662) > {code} -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3053) Enhance JCache documentation

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3053?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3053: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Enhance JCache documentation > ---------------------------- > > Key: ISPN-3053 > URL: https://issues.jboss.org/browse/ISPN-3053 > Project: Infinispan > Issue Type: Task > Components: JCache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > Add documentation on: > - Expiration > - JCache annotations (bring it from the CDI page?) > - Transactions > - invokeEntryProcessor operation > - Cache listeners > - How to use JCache can be used without Maven -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2964) putForExternalRead to L1 not invalidated

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2964?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2964: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > putForExternalRead to L1 not invalidated > ---------------------------------------- > > Key: ISPN-2964 > URL: https://issues.jboss.org/browse/ISPN-2964 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.1.Final > Reporter: Sebastian Tusk > Assignee: William Burns > Attachments: SebastianTusk_ISPN-2964_fix.patch > > > With transactional distributed caches it happens that Cache.putForExternalRead(k,v) places an entry into L1 that never gets invalidated. It seems to happen when the the owner of k doesn't have the entry. In this case the non owner puts k into his cache without having the owner registering this. Usually the owner stores all requesters in L1ManagerImpl.addRequester and sends out invalidations to the requesters. What should happen is that the entry is replicated to the owner. > Cache config: > <namedCache name="entity"> > <jmxStatistics enabled="true" /> > <clustering mode="dist"> > <stateTransfer fetchInMemoryState="false" timeout="20000" /> > <async /> > <l1 enabled="true" /> > <hash numOwners="1"/> > </clustering> > <locking isolationLevel="READ_COMMITTED" > lockAcquisitionTimeout="15000" useLockStriping="false" /> > <eviction maxEntries="10000" strategy="LRU" /> > <expiration maxIdle="100000" wakeUpInterval="5000"/> > <storeAsBinary storeKeysAsBinary="true" storeValuesAsBinary="false" enabled="false" /> > <transaction transactionMode="TRANSACTIONAL" autoCommit="false" lockingMode="OPTIMISTIC"/> > </namedCache> -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3336) Extended Statistics check list

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3336?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3336: -------------------------------- Fix Version/s: 6.1.0.Final (was: 6.0.0.Final) > Extended Statistics check list > ------------------------------ > > Key: ISPN-3336 > URL: https://issues.jboss.org/browse/ISPN-3336 > Project: Infinispan > Issue Type: Task > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 6.1.0.Final > > > * add documentation > * check for duplicate stats; > * check for not exposed statistics > * try to improve the code (reduce the number of access to the CHM) > * add tests to check if they are exported via JMX correctly > * failing test: OptimisticLockingTxClusterExtendedStatisticLogicTest.testWriteSkewOnNonOwner > * failing test: PessimisticLockingTxClusterExtendedStatisticLogicTest.testDeadlockOnNonOwnerWithRemoteTx -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1790) Release script should not rip off comments from POM.XML files

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1790?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1790: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Release script should not rip off comments from POM.XML files > ------------------------------------------------------------- > > Key: ISPN-1790 > URL: https://issues.jboss.org/browse/ISPN-1790 > Project: Infinispan > Issue Type: Enhancement > Components: Build process > Affects Versions: 5.1.0.FINAL > Reporter: Sanne Grinovero > Assignee: Manik Surtani > Priority: Minor > Labels: release.py > > Comparing the git commit which was used to release 5.1.0.Final to the final tag of the released version, reveals some changes which are likely unintended: > * All Copyright statements removed > * All comments removed (useful and unuseful) > * In some way changed the inlined scripts for Google analytics - not sure if it's still working -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1548) Refactor API and Commons in self-contained packages to avoid package splitting issues

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1548?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1548: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Refactor API and Commons in self-contained packages to avoid package splitting issues > ------------------------------------------------------------------------------------- > > Key: ISPN-1548 > URL: https://issues.jboss.org/browse/ISPN-1548 > Project: Infinispan > Issue Type: Task > Components: Core API > Affects Versions: 5.1.0.BETA5 > Reporter: NadirX > Assignee: Tristan Tarrant > > With the split of core into api and commons (ISPN-1490) we have caused split packages (i.e. classes in the same package are split across multiple jars). This causes problems with OSGi (ISPN-1537) and will also be disallowed when signed jars will be made compulsory in EAP. > We therefore need to introduce new packages explicitly for api and commons. This will obviously have some impact on client code. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1368) RpcManagerFactory should not create an RpcManager for local caches

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1368?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1368: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > RpcManagerFactory should not create an RpcManager for local caches > ------------------------------------------------------------------ > > Key: ISPN-1368 > URL: https://issues.jboss.org/browse/ISPN-1368 > Project: Infinispan > Issue Type: Bug > Components: RPC > Affects Versions: 5.0.0.FINAL > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Minor > > As indicated in ISPN-1348, RpcManagerFactory should not create an RpcManager for those caches whose mode is LOCAL,, even if the transport is not null. > Btw, I don't want this fixed till ISPN-1366 is in place, otherwise ISPN-1348 does become a problem and finding a solution for it without ISPN-1366 complicates things greatly. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1146) Improve documentation around transaction and locking

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1146?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1146: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Improve documentation around transaction and locking > ---------------------------------------------------- > > Key: ISPN-1146 > URL: https://issues.jboss.org/browse/ISPN-1146 > Project: Infinispan > Issue Type: Task > Components: Transactions > Reporter: Mircea Markus > Assignee: Mircea Markus > > As suggested by Jonathan Halliday: > - preserving some subset of the existing transactional guarantees is all well and good BUT if the user is relying on additional 'guarantees' that are not preserved in all cases then they'll be in trouble. Therefore, it's essential to document not just what the minimum expected guarantees for a given config are, but also that no additional properties that may coincidently be observed are actually guaranteed. Some vendors go further and explicitly document the bad things that may happen with given settings, since in some cases these are not easy to reproduce in testing. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-825) Consider staggering remote get requests when using DIST

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-825?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-825: ------------------------------- Fix Version/s: (was: 6.0.0.Final) > Consider staggering remote get requests when using DIST > ------------------------------------------------------- > > Key: ISPN-825 > URL: https://issues.jboss.org/browse/ISPN-825 > Project: Infinispan > Issue Type: Feature Request > Components: RPC > Affects Versions: 4.1.0.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Priority: Critical > Labels: optimization, performance > > In DIST mode, when a request is made on a key that is not mapped locally, a remote get is sent to all data owners of that key and the first response is used. This can add unnecessary load on the network as all nodes still eventually respond, and if values are large this can cause a lot of unnecessary network traffic. > The purpose of broadcasting to all data owners is so that (1) if one is down, another could still respond (2) if one is overloaded, others may respond faster. > A solution around this could be based on either (or both) of: > * Provide a configurable stagger timeout, e.g. 100ms. E.g., RPC to (random) Owner1. Wait for timeout t. If no response, RPC to Owner2. etc. > * Always broadcast to a (configurable) subset of owners, e.g., always 2 even if numOwners is 5. > Needs careful thought and design. -- 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, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2013