December 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3779) Simplification and code cleanup in InvocationContext implementations

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-3779: ------------------------------------- Summary: Simplification and code cleanup in InvocationContext implementations Key: ISPN-3779 URL: https://issues.jboss.org/browse/ISPN-3779 Project: Infinispan Issue Type: Enhancement Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 6.1.0.Final The class hierarchy of InvocationContext implementors got complex and is also leading to additional memory costs because of alignment requirements. I've been simplifying some code, specifically focusing on the _SingleKeyNonTxInvocationContext_ but not only. -- 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
0
0 / 0

[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.... ] William Burns updated ISPN-3364: -------------------------------- Fix Version/s: 6.1.0.Final > 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 > Fix For: 6.1.0.Final > > 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
0
0 / 0

[JBoss JIRA] (ISPN-3745) Forwarded Prepare/Commit executed after transaction finished

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3745?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-3745: ------------------------------------ [~rvansa] What's the cache configuration? The forwarding is always done synchronously, so node A couldn't receive the prepare response and send the commit until C finished its forwarding. > Forwarded Prepare/Commit executed after transaction finished > ------------------------------------------------------------ > > Key: ISPN-3745 > URL: https://issues.jboss.org/browse/ISPN-3745 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 6.0.0.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 620 > > Replicated TX cache, nodes A, B, C > 0. A and B have topology 2, C already got topology 3 > 1. A sends prepare with topology 2 to B and C, both apply the prepare and respond > 2. C forwards prepare to B with topology 3 > 3. A sends commit with topology 2 to B and C, both commit and respond > 4. again, C forwards prepare to B with topology 3 > 5. A and B get updated topology id > 6. A executes another transaction on the same entry > 7. prepare and commit from first transaction with topology 3 arrive at B - B overwrites (or removes) the entry again > Result: on B we have inconsistent state -- 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
0
0 / 0

[JBoss JIRA] (ISPN-3721) Extend remote get test scenarios to test the joiner state

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3721?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3721: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Final 7.0.0.Alpha1 Resolution: Done > Extend remote get test scenarios to test the joiner state > --------------------------------------------------------- > > Key: ISPN-3721 > URL: https://issues.jboss.org/browse/ISPN-3721 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 6.1.0.Final, 7.0.0.Final, 7.0.0.Alpha1 > > > I got a failure in testScenario6, and I think it's because the originator retried the get command on the joiner, but the joiner hadn't installed the currentTopology+2 topology, and ClusteredGetCommand.perform() returned an unsure response. I guess I we'll have to rethink the unsure response stuff after all... > Here's the log: https://www.dropbox.com/s/dka0vdwm719klkm/RemoteGetDusingStateTransfer.tgz -- 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
0
0 / 0

[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-3633: ------------------------------------- I was never able to reproduce this except when the issue was related to when the ST occurred in the middle of a prepare commit step, but I will revisit and see if I can find anything else. Do you happen to have a trace of when this occurs with non tx caches? > InvalidateL1Command during ST should not cancel writing the entry by ST > ----------------------------------------------------------------------- > > Key: ISPN-3633 > URL: https://issues.jboss.org/browse/ISPN-3633 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry. > Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once. -- 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
0
0 / 0

[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] Work on ISPN-3633 started by William Burns. > InvalidateL1Command during ST should not cancel writing the entry by ST > ----------------------------------------------------------------------- > > Key: ISPN-3633 > URL: https://issues.jboss.org/browse/ISPN-3633 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry. > Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once. -- 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
0
0 / 0

[JBoss JIRA] (ISPN-3737) L1 requestor registered after value read

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3737?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3737: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 6.1.0.Final Resolution: Done > L1 requestor registered after value read > ---------------------------------------- > > Key: ISPN-3737 > URL: https://issues.jboss.org/browse/ISPN-3737 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 6.1.0.Final > > > As the L1 requestor is registered only after the value is retrieved from data container, the (transactional) update of the value may not invalide the entry after write and the cache gets inconsistent. > Consider this interleaving of operations (G=get request from other node, C=commit) > R: read value -> old value > C: update old -> new > C: notify requestors for key > R: add requestor for key -- 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
0
0 / 0

[JBoss JIRA] (ISPN-3778) ClusteredCacheWithAsyncDirTest throws lots of "org.h2.jdbc.JdbcSQLException: Unique index or primary key violation"

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-3778: ----------------------------------- Summary: ClusteredCacheWithAsyncDirTest throws lots of "org.h2.jdbc.JdbcSQLException: Unique index or primary key violation" Key: ISPN-3778 URL: https://issues.jboss.org/browse/ISPN-3778 Project: Infinispan Issue Type: Bug Components: Querying, Test Suite Affects Versions: 6.0.0.Final Reporter: Adrian Nistor Assignee: Adrian Nistor The tests runs two nodes on same machine, each configured to use a jdbc cachestore running on same database. This clash leads to: {noformat} 2013-12-02 15:50:26,159 ERROR [JdbcStringBasedStore] (AsyncStoreProcessor-LuceneIndexesData_custom1-23) ISPN008024: Error while storing string key to database; key: '_0.fdx|0|16384|person' org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: "PRIMARY_KEY_E ON PUBLIC.""ISPN_STRING_TABLE_LuceneIndexesData_custom1""(ID_COLUMN)"; SQL statement: INSERT INTO "ISPN_STRING_TABLE_LuceneIndexesData_custom1" (DATA_COLUMN, TIMESTAMP_COLUMN, ID_COLUMN) VALUES(?,?,?) [23505-166] at org.h2.message.DbException.getJdbcSQLException(DbException.java:329) at org.h2.message.DbException.get(DbException.java:169) at org.h2.message.DbException.get(DbException.java:146) at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:81) at org.h2.index.TreeIndex.add(TreeIndex.java:62) at org.h2.table.RegularTable.addRow(RegularTable.java:121) at org.h2.command.dml.Insert.insertRows(Insert.java:124) at org.h2.command.dml.Insert.update(Insert.java:84) at org.h2.command.CommandContainer.update(CommandContainer.java:73) at org.h2.command.Command.executeUpdate(Command.java:226) at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:143) at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:129) at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeUpdate(NewProxyPreparedStatement.java:105) at org.infinispan.persistence.jdbc.stringbased.JdbcStringBasedStore.write(JdbcStringBasedStore.java:166) at org.infinispan.persistence.async.AsyncCacheWriter.applyModificationsSync(AsyncCacheWriter.java:154) at org.infinispan.persistence.async.AsyncCacheWriter$AsyncStoreProcessor.retryWork(AsyncCacheWriter.java:329) at org.infinispan.persistence.async.AsyncCacheWriter$AsyncStoreProcessor.run(AsyncCacheWriter.java:313) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) 2013-12-02 15:50:26,392 ERROR [JdbcStringBasedStore] (persistence-thread-2,NodeL) ISPN008007: SQL error while fetching all StoredEntries org.h2.jdbc.JdbcSQLException: Table "ISPN_STRING_TABLE_LuceneIndexesMetadata_custom1" not found; SQL statement: SELECT DATA_COLUMN,ID_COLUMN, TIMESTAMP_COLUMN FROM "ISPN_STRING_TABLE_LuceneIndexesMetadata_custom1" WHERE TIMESTAMP_COLUMN > ? OR TIMESTAMP_COLUMN < 0 [42102-166] at org.h2.message.DbException.getJdbcSQLException(DbException.java:329) at org.h2.message.DbException.get(DbException.java:169) at org.h2.message.DbException.get(DbException.java:146) at org.h2.command.Parser.readTableOrView(Parser.java:4757) at org.h2.command.Parser.readTableFilter(Parser.java:1084) at org.h2.command.Parser.parseSelectSimpleFromPart(Parser.java:1690) at org.h2.command.Parser.parseSelectSimple(Parser.java:1797) at org.h2.command.Parser.parseSelectSub(Parser.java:1684) at org.h2.command.Parser.parseSelectUnion(Parser.java:1527) at org.h2.command.Parser.parseSelect(Parser.java:1515) at org.h2.command.Parser.parsePrepared(Parser.java:405) at org.h2.command.Parser.parse(Parser.java:279) at org.h2.command.Parser.parse(Parser.java:251) at org.h2.command.Parser.prepareCommand(Parser.java:217) at org.h2.engine.Session.prepareLocal(Session.java:415) at org.h2.engine.Session.prepareCommand(Session.java:364) at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1111) at org.h2.jdbc.JdbcPreparedStatement.<init>(JdbcPreparedStatement.java:71) at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:266) at com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement(NewProxyConnection.java:213) at org.infinispan.persistence.jdbc.stringbased.JdbcStringBasedStore$2.call(JdbcStringBasedStore.java:321) at org.infinispan.persistence.jdbc.stringbased.JdbcStringBasedStore$2.call(JdbcStringBasedStore.java:309) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) {noformat} Despite these exceptions being logged, the test does not fail. -- 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
0
0 / 0

[JBoss JIRA] (ISPN-3737) L1 requestor registered after value read

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3737?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3737: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2242 > L1 requestor registered after value read > ---------------------------------------- > > Key: ISPN-3737 > URL: https://issues.jboss.org/browse/ISPN-3737 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: 620 > > As the L1 requestor is registered only after the value is retrieved from data container, the (transactional) update of the value may not invalide the entry after write and the cache gets inconsistent. > Consider this interleaving of operations (G=get request from other node, C=commit) > R: read value -> old value > C: update old -> new > C: notify requestors for key > R: add requestor for key -- 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
0
0 / 0

[JBoss JIRA] (ISPN-3606) FileCacheStoreConfig JavaDoc incorrectly states that 'fetchPersistentState' is only supported in 'replication' and 'invalidation' mode.

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-3606?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-3606: ---------------------------- Status: Closed (was: Pull Request Sent) Resolution: Done > FileCacheStoreConfig JavaDoc incorrectly states that 'fetchPersistentState' is only supported in 'replication' and 'invalidation' mode. > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3606 > URL: https://issues.jboss.org/browse/ISPN-3606 > Project: Infinispan > Issue Type: Bug > Components: Documentation > Affects Versions: 5.3.0.Final > Reporter: Duncan Doyle > Assignee: Mircea Markus > Priority: Minor > Labels: 620 > > The JavaDoc of FileCacheStoreConfig states that 'fetchPersistentStore' is only supported in 'replication' and 'invalidation' mode: [quote]Finally, setting it to true only makes sense if in a clustered environment, and only 'replication' and 'invalidation' cluster modes are supported.[/quote] > See: http://docs.jboss.org/infinispan/5.3/apidocs/org/infinispan/loaders/file/... > After a discussion with Dan (dberindei) on IRC, 'fetchPersistentState' seems to be supported in 'distributed' mode as well. JavaDoc needs to be updated. -- 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
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2013