September 2013 - infinispan-issues

[JBoss JIRA] (ISPN-484) Querying over HotRod

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-484?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-484: ------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.CR1) > Querying over HotRod > -------------------- > > Key: ISPN-484 > URL: https://issues.jboss.org/browse/ISPN-484 > Project: Infinispan > Issue Type: Feature Request > Components: Querying, Remote protocols > Reporter: Galder Zamarreño > Assignee: Adrian Nistor > Priority: Blocker > Labels: jdg62 > Fix For: 6.0.0.Beta2, 6.0.0.Final > > > The requirements are captured here: https://community.jboss.org/wiki/RemoteQueryDesignInInfinispan -- 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-3273) Dist L1 owners that aren't primary don't respect assumeOriginKeptEntryInL1

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3273?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3273: -------------------------------- Fix Version/s: 6.1.0.Final (was: 6.0.0.CR1) > Dist L1 owners that aren't primary don't respect assumeOriginKeptEntryInL1 > -------------------------------------------------------------------------- > > Key: ISPN-3273 > URL: https://issues.jboss.org/browse/ISPN-3273 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Reporter: William Burns > Assignee: William Burns > Fix For: 6.1.0.Final > > Attachments: DistSyncFuncTest.java > > > When a write operation occurs causing a L1 invalidation, there is a boolean to say assumeOriginKeptEntryInL1 which means the owner won't send an invalidation to the originating node that caused this update. This works fine for the primary owner, however any additional backups think the origin is the primary owner and such send invalidations to possibly the real origin. > -This affects both tx and non tx caches. Tx caches that are sync don't see the problem since locking prevents the invalidation, however it causes an unneeded network roundtrip which can cause delay.- > Actually this only affects non-tx caches, as tx caches send the prepare/commit directly to the owner(s) instead of having it relayed. -- 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-484) Querying over HotRod

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-484?page=com.atlassian.jira.plugin.s... ] Mircea Markus resolved ISPN-484. -------------------------------- Resolution: Done > Querying over HotRod > -------------------- > > Key: ISPN-484 > URL: https://issues.jboss.org/browse/ISPN-484 > Project: Infinispan > Issue Type: Feature Request > Components: Querying, Remote protocols > Reporter: Galder Zamarreño > Assignee: Adrian Nistor > Priority: Blocker > Labels: jdg62 > Fix For: 6.0.0.Beta2, 6.0.0.CR1 > > > The requirements are captured here: https://community.jboss.org/wiki/RemoteQueryDesignInInfinispan -- 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-2402) Cache operations or transactions should never fail with SuspectException

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2402?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-2402. --------------------------------- Resolution: Duplicate Issue ISPN-2577 already tracks this. > Cache operations or transactions should never fail with SuspectException > ------------------------------------------------------------------------ > > Key: ISPN-2402 > URL: https://issues.jboss.org/browse/ISPN-2402 > Project: Infinispan > Issue Type: Task > Components: RPC, State transfer > Affects Versions: 5.2.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: 5.2.x > Fix For: 6.0.0.CR1 > > Attachments: vrstt.log > > > This is an extension of ISPN-1896 of sorts, but for all the cache operations that are visible to the user. > After a node leaves, the other nodes that have sent commands to that node should either ignore SuspectExceptions or, if not possible, they should retry the operation (e.g. if they didn't get any response back). > For example, VersionReplStateTransferTest quite often on my machine with a SuspectException, because the versioned prepare command expects a response from the coordinator and the coordinator has just left. -- 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 reassigned ISPN-3542: ----------------------------------- Assignee: William Burns (was: Mircea Markus) > 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 > 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

[JBoss JIRA] (ISPN-3542) Read Only transaction optimization doesn't work properly for RepeatableRead

by William Burns (JIRA)

William Burns created ISPN-3542: ----------------------------------- Summary: 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: Mircea Markus 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

[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: -------------------------------- Attachment: ISPN-3542-patch Patch file that tests and reproduces issue > 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: Mircea Markus > 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

[JBoss JIRA] (ISPN-3402) Add JDBC Cache Store config to RHQ plugin

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3402?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3402: -------------------------------- Fix Version/s: 6.0.0.CR1 (was: 6.0.0.Alpha2) > Add JDBC Cache Store config to RHQ plugin > ----------------------------------------- > > Key: ISPN-3402 > URL: https://issues.jboss.org/browse/ISPN-3402 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores, Server > Reporter: William Burns > Assignee: William Burns > Fix For: 6.0.0.CR1 > > > ISPN-3350 was added to enhance some of the RHQ endpoints to allow for better runtime configuration support. However ISPN-3290 is also concurrently changing cache stores. Some changes for ISPN-3290 were mentioned to be possibly changing how the JDBC cache stores are configured and as such this has been excluded from ISPN-3350 to not implement it twice. > This is just to add in the support JDBC cache stores as they 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-3287) Possible inconsistency with concurrent transactions during state transfer

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3287?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3287: -------------------------------- Fix Version/s: 6.0.0.Final > Possible inconsistency with concurrent transactions during state transfer > ------------------------------------------------------------------------- > > Key: ISPN-3287 > URL: https://issues.jboss.org/browse/ISPN-3287 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency, State transfer > Affects Versions: 5.3.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 6.0.0.CR1, 6.0.0.Final > > > It looks like there is a data race between the state transfer thread and a concurrent transaction in EntryWrappingInterceptor.commitEntryIfNeeded: > tx: commitContextEntry() > ST: stateConsumer.isKeyUpdated(k)? false > tx: stateConsumer.addUpdatedKey(k) > ST: commitContextEntry() > We probably need some synchronization here, maybe using EquivalentConcurrentHashMapV8.computeIfAbsent(). -- 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-3290) Redesign CacheStore API

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3290?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3290: -------------------------------- Fix Version/s: 6.0.0.Alpha4 (was: 6.0.0.Beta2) > Redesign CacheStore API > ----------------------- > > Key: ISPN-3290 > URL: https://issues.jboss.org/browse/ISPN-3290 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Critical > Fix For: 6.0.0.Alpha4, 6.0.0.Final > > > the cache store API should be redesigned in the scope of 6.0. See all the related JIRAs for requirements. > Also a discussion has been started here: https://community.jboss.org/wiki/CacheLoaderAndCacheStoreSPIRedesign -- 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