November 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3611) Service jboss.infinispan.default failed to start on IBM JDK 6, argument type mismatch

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3611?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3611: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1013242|https://bugzilla.redhat.com/show_bug.cgi?id=1013242] from NEW to POST > Service jboss.infinispan.default failed to start on IBM JDK 6, argument type mismatch > ------------------------------------------------------------------------------------- > > Key: ISPN-3611 > URL: https://issues.jboss.org/browse/ISPN-3611 > Project: Infinispan > Issue Type: Bug > Reporter: Mircea Markus > Assignee: William Burns > Labels: 620 > Fix For: 6.0.0.CR2 > > -- 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

12 years, 5 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3633: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1019348|https://bugzilla.redhat.com/show_bug.cgi?id=1019348] from ASSIGNED to POST > 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3599) CommitCommand with replayed PrepareCommand executes rollback and then commit

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3599?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3599: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1016054|https://bugzilla.redhat.com/show_bug.cgi?id=1016054] from NEW to POST > CommitCommand with replayed PrepareCommand executes rollback and then commit > ---------------------------------------------------------------------------- > > Key: ISPN-3599 > URL: https://issues.jboss.org/browse/ISPN-3599 > Project: Infinispan > Issue Type: Bug > Components: State transfer, Transactions > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Pedro Ruivo > Priority: Critical > Labels: 620 > Fix For: 6.0.0.CR2, 6.0.0.Final > > > During state-transfer in tx cache, the node can receive {{CommitCommand}} from other node. After the node gets transaction data for affected segments, it creates the transaction with {{missingLookedUpEntries=true}} and the {{CommitCommand}} can be executed. > In this command's {{perform(...)}} the transaction is *first* marked as completed, then it enters the interceptor chain. There, the {{PrepareCommand}} is created in {{StateTransferInterceptor.visitCommitCommand}} but after this is processed the {{TxInterceptor}} finds out that the transaction is already completed and executes {{RollbackCommand}}, clearing locks etc. > Nevertheless, {{StateTransferInterceptor}} executes the initial {{CommitCommand}} afterwards. I suspect that this may be executed without the locks held. > Anyway, it is not correct to execute both commit and rollback on the same transaction. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3518) 1PC can cause a window of inconsistency with L1 invalidation

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3518?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3518: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2195 > 1PC can cause a window of inconsistency with L1 invalidation > ------------------------------------------------------------ > > Key: ISPN-3518 > URL: https://issues.jboss.org/browse/ISPN-3518 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: William Burns > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > The L1TxInterceptor currently doesn't block on L1 invalidations during a 1PC. This can cause an inconsistent view of data across non owner nodes. > Example: > {quote} > Node A owns k with value of v1 > Node B has k in L1 with value of v1 > tx1 started > Node A put k -> v2 > Node A sends invalidation > Node A commits > tx1 completed > tx2 started > Node B get k returns v1 from L1 > tx2 completed > Node B gets invalidation for k > tx3 started > Node B get k remotely retrieves v2 from Node A > tx3 completed > {quote} > We need to make sure that all L1 invalidations in Tx mode are completed before completing the transaction. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2475) When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2475?page=com.atlassian.jira.plugin.... ] Work on ISPN-2475 started by William Burns. > When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners > ----------------------------------------------------------------------------------- > > Key: ISPN-2475 > URL: https://issues.jboss.org/browse/ISPN-2475 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.1.0.FINAL, 6.0.0.CR1 > Reporter: Dan Berindei > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > Copied from the parent: > {quote} > [...] we can keep track of the consistent hashes in the last 10 minutes (or whatever the L1 lifespan is) and the time of the last invalidation sent for each key. When we need to send a new invalidation, we add the owners in all the consistent hashes since the last invalidation to the invalidation command recipients. > {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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3686) Fix the release script to upload the xsd

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3686?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3686: -------------------------------- Fix Version/s: 6.0.0.CR2 > Fix the release script to upload the xsd > ---------------------------------------- > > Key: ISPN-3686 > URL: https://issues.jboss.org/browse/ISPN-3686 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Adrian Nistor > Fix For: 6.0.0.CR2 > > > I just noticed that our new website does not host the infinispan schemas > which should be at: > http://www.infinispan.org/schemas/infinispan-config-6.0.xsd > We need to fix the release script to handle this -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3686) Fix the release script to upload the xsd

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3686: ----------------------------------- Summary: Fix the release script to upload the xsd Key: ISPN-3686 URL: https://issues.jboss.org/browse/ISPN-3686 Project: Infinispan Issue Type: Task Reporter: Mircea Markus Assignee: Adrian Nistor I just noticed that our new website does not host the infinispan schemas which should be at: http://www.infinispan.org/schemas/infinispan-config-6.0.xsd We need to fix the release script to handle this -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2475) When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2475?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2475: -------------------------------- Labels: 620 (was: ) > When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners > ----------------------------------------------------------------------------------- > > Key: ISPN-2475 > URL: https://issues.jboss.org/browse/ISPN-2475 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.1.0.FINAL, 6.0.0.CR1 > Reporter: Dan Berindei > Assignee: William Burns > Labels: 620 > Fix For: 6.1.0.Final > > > Copied from the parent: > {quote} > [...] we can keep track of the consistent hashes in the last 10 minutes (or whatever the L1 lifespan is) and the time of the last invalidation sent for each key. When we need to send a new invalidation, we add the owners in all the consistent hashes since the last invalidation to the invalidation command recipients. > {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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2475) When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2475?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2475: -------------------------------- Priority: Critical (was: Major) > When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners > ----------------------------------------------------------------------------------- > > Key: ISPN-2475 > URL: https://issues.jboss.org/browse/ISPN-2475 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.1.0.FINAL, 6.0.0.CR1 > Reporter: Dan Berindei > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 6.1.0.Final > > > Copied from the parent: > {quote} > [...] we can keep track of the consistent hashes in the last 10 minutes (or whatever the L1 lifespan is) and the time of the last invalidation sent for each key. When we need to send a new invalidation, we add the owners in all the consistent hashes since the last invalidation to the invalidation command recipients. > {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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2475) When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2475?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2475: -------------------------------- Fix Version/s: 6.0.0.Final (was: 6.1.0.Final) > When L1.onRehash is enabled, L1 invalidations should be sent to the previous owners > ----------------------------------------------------------------------------------- > > Key: ISPN-2475 > URL: https://issues.jboss.org/browse/ISPN-2475 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.1.0.FINAL, 6.0.0.CR1 > Reporter: Dan Berindei > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 6.0.0.Final > > > Copied from the parent: > {quote} > [...] we can keep track of the consistent hashes in the last 10 minutes (or whatever the L1 lifespan is) and the time of the last invalidation sent for each key. When we need to send a new invalidation, we add the owners in all the consistent hashes since the last invalidation to the invalidation command recipients. > {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

12 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2013