September 2013 - infinispan-issues

[JBoss JIRA] (ISPN-1741) Remove old and deprecated pre-5.0 Configuration objects

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1741?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-1741. --------------------------------- Resolution: Out of Date done by Pedro in another PR. > Remove old and deprecated pre-5.0 Configuration objects > ------------------------------------------------------- > > Key: ISPN-1741 > URL: https://issues.jboss.org/browse/ISPN-1741 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration > Affects Versions: 5.2.0.Final > Reporter: Manik Surtani > Assignee: Tristan Tarrant > Fix For: 6.0.0.Beta2, 6.0.0.CR1 > > > Remove the deprecated Configuration object altogether from the code base, and update all public APIs and SPIs accordingly. -- 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-2702) RecoveryWithCustomCacheDistTest.testNodeCrashesAfterPrepare failing randomly

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2702?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2702: -------------------------------- Fix Version/s: (was: 6.0.0.Beta2) > RecoveryWithCustomCacheDistTest.testNodeCrashesAfterPrepare failing randomly > ---------------------------------------------------------------------------- > > Key: ISPN-2702 > URL: https://issues.jboss.org/browse/ISPN-2702 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Reporter: Galder Zamarreño > Assignee: Pedro Ruivo > Labels: testsuite_stability > Fix For: 6.0.0.CR1 > > Attachments: RecoveryWithCustomCacheDistTest.log.gz, testNodeCrashesAfterPrepare-1.log > > > {code}testNodeCrashesAfterPrepare(org.infinispan.tx.recovery.RecoveryWithCustomCacheDistTest) Time elapsed: 0.083 sec <<< FAILURE! > java.lang.RuntimeException: javax.transaction.xa.XAException > at org.infinispan.tx.recovery.RecoveryTestUtil.prepareTransaction(RecoveryTestUtil.java:58) > at org.infinispan.tx.recovery.RecoveryWithDefaultCacheDistTest.testNodeCrashesAfterPrepare(RecoveryWithDefaultCacheDistTest.java:124) > 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:715) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237) > 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:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:680) > Caused by: javax.transaction.xa.XAException > at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:161) > at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:123) > at org.infinispan.transaction.xa.TransactionXaAdapter.prepare(TransactionXaAdapter.java:110) > at org.infinispan.tx.recovery.RecoveryTestUtil.prepareTransaction(RecoveryTestUtil.java:56) > ... 22 more{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-3447) LevelDBCacheStore tests fail to compile with latest core snapshot

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3447?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3447: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Out of Date > LevelDBCacheStore tests fail to compile with latest core snapshot > ----------------------------------------------------------------- > > Key: ISPN-3447 > URL: https://issues.jboss.org/browse/ISPN-3447 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 6.0.0.Beta2 > > > Error: > {code}[ERROR] COMPILATION ERROR : > [INFO] ------------------------------------------------------------- > [ERROR] /Users/g/Go/code/cachestores/cachestore-leveldb.git/src/test/java/org/infinispan/loaders/leveldb/config/ConfigurationTest.java:[76,82] method cacheStore in class org.infinispan.configuration.cache.LegacyStoreConfigurationBuilder cannot be applied to given types; > required: org.infinispan.loaders.CacheStore > found: org.infinispan.loaders.leveldb.LevelDBCacheStore > reason: actual argument org.infinispan.loaders.leveldb.LevelDBCacheStore cannot be converted to org.infinispan.loaders.CacheStore by method invocation conversion{code} > [~rvansa], is this related to your changes? -- 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-2522) The org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest (StateTransferFunctionTest) tests fail periodically

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2522?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2522: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.Beta2) > The org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest (StateTransferFunctionTest) tests fail periodically > --------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2522 > URL: https://issues.jboss.org/browse/ISPN-2522 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Anna Manukyan > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 6.0.0.Final > > > The following tests of org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest class are failing periodically during JDG 6.1.0.ER3 build testing: > org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest.testSTWithWritingNonTxThread > org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest.testSTWithWritingTxThread > You can find the failure logs here: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > The same issue happens to org.infinispan.statetranser.StateTransferFunctionTest tests(the parent test class). > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... -- 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-3183) HotRod RollUps from 5.2 to 5.3 -- target can't obtain formerly stored data from RCS

by Tomas Sykora (JIRA)

[ https://issues.jboss.org/browse/ISPN-3183?page=com.atlassian.jira.plugin.... ] Tomas Sykora commented on ISPN-3183: ------------------------------------ Tristan's PR should fix this problem. I got it work and successfully migrated data using hotrod migrator from jdg 6.1 (ispn schema 5.2) to the latest ispn server (ispn schema 6.0). Nice work! Thank you > HotRod RollUps from 5.2 to 5.3 -- target can't obtain formerly stored data from RCS > ----------------------------------------------------------------------------------- > > Key: ISPN-3183 > URL: https://issues.jboss.org/browse/ISPN-3183 > Project: Infinispan > Issue Type: Bug > Reporter: Tomas Sykora > Assignee: Tristan Tarrant > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.Beta2 > > Attachments: 52to52sourceTrace, 52to52targetTrace, 52to53sourceTrace, 52to53targetTrace > > > Scenario (typical for rollups): > Start source node, put entries. > Start target node which is pointing to source (source is his RemoteCacheStore now) and try to get entries. > For 5.2 to 5.2 working perfectly. > For 5.2 source and 5.3 target -- we have problems here. > Sorry that I can't provide any valuable info beside TRACEs. > 4 TRACE logs -- rollups from 5.2 to 5.2 source log and target log + rollups from 5.2 to 5.3 source log and target log. > Very quick summary: > 5.2 to 5.2 on target: Entry exists in loader? true > 5.2 to 5.3 on targer: > 16:21:41,508 TRACE [org.infinispan.container.EntryFactoryImpl] (HotRodServerWorker-2) Exists in context? null > 16:21:41,508 TRACE [org.infinispan.container.EntryFactoryImpl] (HotRodServerWorker-2) Retrieved from container null > What changed in RemoteCacheStore. What changed in HotRod? Any idea? Let me know, thank you! > -- 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-3543) Remove deprecated configuration elements from default JGroups config

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-3543: ------------------------------------- Summary: Remove deprecated configuration elements from default JGroups config Key: ISPN-3543 URL: https://issues.jboss.org/browse/ISPN-3543 Project: Infinispan Issue Type: Bug Components: Server Affects Versions: 6.0.0.Beta1 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Priority: Minor Fix For: 6.0.0.Beta2 -- 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-3543) Remove deprecated configuration elements from default JGroups config

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3543?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3543: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-server/pull/159 > Remove deprecated configuration elements from default JGroups config > -------------------------------------------------------------------- > > Key: ISPN-3543 > URL: https://issues.jboss.org/browse/ISPN-3543 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.0.Beta1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 6.0.0.Beta2 > > -- 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-3183) HotRod RollUps from 5.2 to 5.3 -- target can't obtain formerly stored data from RCS

by Tomas Sykora (JIRA)

[ https://issues.jboss.org/browse/ISPN-3183?page=com.atlassian.jira.plugin.... ] Tomas Sykora commented on ISPN-3183: ------------------------------------ Not absolutely sure whether this is the proper way of testing this... but I consider this scenario should work 2 JDG 6.1.GA as source cluster, 2 latest ispn-servers with this PR as a target cluster: 08:17:19,579 WARN [org.jgroups.protocols.UDP] (multicast receiver,shared=udp) [JGRP00010] packe08:17:19,579 WARN [org.jgroups.protocols.UDP] (multicast receiver,shared=udp) [JGRP00010] packet from 192.168.2.103:45688 has different version (3.4.0) than ours (3.3.4); packet is discarded (received 13 identical messages from 192.168.2.103:45688 in the last 66549 ms) t from 192.168.2.103:45688 has different version (3.4.0) than ours (3.3.4); packet is discarded (received 13 identical messages from 192.168.2.103:45688 in the last 66549 ms) Looks like we need to deal somehow with different version of jgroups as well. What do you thing? Any simple workaround for that? Thanks! > HotRod RollUps from 5.2 to 5.3 -- target can't obtain formerly stored data from RCS > ----------------------------------------------------------------------------------- > > Key: ISPN-3183 > URL: https://issues.jboss.org/browse/ISPN-3183 > Project: Infinispan > Issue Type: Bug > Reporter: Tomas Sykora > Assignee: Tristan Tarrant > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.Beta2 > > Attachments: 52to52sourceTrace, 52to52targetTrace, 52to53sourceTrace, 52to53targetTrace > > > Scenario (typical for rollups): > Start source node, put entries. > Start target node which is pointing to source (source is his RemoteCacheStore now) and try to get entries. > For 5.2 to 5.2 working perfectly. > For 5.2 source and 5.3 target -- we have problems here. > Sorry that I can't provide any valuable info beside TRACEs. > 4 TRACE logs -- rollups from 5.2 to 5.2 source log and target log + rollups from 5.2 to 5.3 source log and target log. > Very quick summary: > 5.2 to 5.2 on target: Entry exists in loader? true > 5.2 to 5.3 on targer: > 16:21:41,508 TRACE [org.infinispan.container.EntryFactoryImpl] (HotRodServerWorker-2) Exists in context? null > 16:21:41,508 TRACE [org.infinispan.container.EntryFactoryImpl] (HotRodServerWorker-2) Retrieved from container null > What changed in RemoteCacheStore. What changed in HotRod? Any idea? Let me know, thank you! > -- 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-3266) Pessimistic Force Write Lock doesn't acquire remote lock

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3266?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3266: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2096 > Pessimistic Force Write Lock doesn't acquire remote lock > -------------------------------------------------------- > > Key: ISPN-3266 > URL: https://issues.jboss.org/browse/ISPN-3266 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache, Locking and Concurrency > Affects Versions: 5.3.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 6.0.0.Beta2 > > Attachments: DistSyncL1PessimisticFuncTest.java > > > Looking into FORCE_WRITE_LOCK it appears it only acquires a local lock in PessimisticLockingInterceptor. Thinking about this, it seems this should acquire only a remote lock on the primary node. Currently this isn't going to block writes at all. I am guessing this was just an oversight when redoing the locking mechanism. > This causes other issues such as L1 inconsistencies which is how I ran into this and the locking should only occur on the remote node. -- 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-3542) Read Only transaction optimization doesn't work properly for RepeatableRead

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3542?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3542: -------------------------------- Fix Version/s: 6.0.0.Beta2 > Read Only transaction optimization doesn't work properly for RepeatableRead > --------------------------------------------------------------------------- > > Key: ISPN-3542 > URL: https://issues.jboss.org/browse/ISPN-3542 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 6.0.0.Beta1 > Reporter: William Burns > Assignee: William Burns > Fix For: 6.0.0.Beta2 > > Attachments: ISPN-3542-patch > > > There is a readOnly optimization that Infinispan does to make sure we don't do a 2PC when there is no data to update. However the code for this does > {code} > public boolean isReadOnly() { > return (modifications == null || modifications.isEmpty()) && (lookedUpEntries == null || lookedUpEntries.isEmpty()); > } > {code} > For repeatable read we always add a value to lookedUpEntries so this optimization never works that isolation level. > Looking closer it seems we do a 1PC when it is readOnly to clean up values, so there shouldn't be a need to care about lookedUpEntries (my guess is this was done as a way to test for locks). -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2013