November 2013 - infinispan-issues

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

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3745?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3745: -------------------------------- Assignee: Dan Berindei (was: Mircea Markus) > 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 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3758) Wrong worker-threads default value description in Infinispan server xsd

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3758?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3758: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 6.1.0.Final Resolution: Done > Wrong worker-threads default value description in Infinispan server xsd > ----------------------------------------------------------------------- > > Key: ISPN-3758 > URL: https://issues.jboss.org/browse/ISPN-3758 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 6.0.0.Final > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Priority: Minor > Fix For: 6.1.0.Final > > > In build/src/main/resources-ispn/docs/schema/jboss-infinispan-endpoint_6_0.xsd: > {quote} > Sets the number of worker threads. Defaults two 2 * number of cores > {quote} > This is correct description for Infinispan Server API, ProtocolServerConfigurationBuilder, but server distribution employs different default value. > In integration/src/main/java/org/infinispan/server/endpoint/subsystem/ProtocolServiceSubsystemAdd.java: > {quote} > private static final int DEFAULT_WORKER_THREADS = 160; > {quote} > It actually uses 160. -- 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 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3738) Entry version gets lost during topology change -> NPE

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3738?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3738: -------------------------------- Assignee: Pedro Ruivo (was: Mircea Markus) > Entry version gets lost during topology change -> NPE > ----------------------------------------------------- > > Key: ISPN-3738 > URL: https://issues.jboss.org/browse/ISPN-3738 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.Final > Reporter: Radim Vansa > Assignee: Pedro Ruivo > Priority: Critical > > Replicated TX cache with WSC, A, B are in cluster, C is joining > 0. The current CH already contains A and B as owners, C is joining (is not primary owner of anything yet). B is primary owner of K=V. > 1. A sends PrepareCommand to B and C with put(K, V) (V is null on all nodes) > 2. C receives PrepareCommand and responds with no versions (it is not primary owner) > 3. topology changes on B - primary ownership of K is transfered to C > 4. B receives PrepareCommand, responds without K's version (it is not primary) > 5. B forwards the Prepare to C as it sees that the command has lower topology ID > 6. C responds to B's prepare with version of K > 7. K version is *not* added to B's response, B responds to A > 8. A finds out that topology has changed, forwards prepare to C > 9. C responds to C's prepare with version of K > 10. A receives C's response, but the versions are not added to transaction > 11. A sends out CommitCommand missing version of K > 12. all nodes record K=V without version as usual ImmortalCacheEntry > 13. the next time we try to increase version of K=V, we fail with NPE in SimpleClusteredVersionGenerator (actually when it tries to throw IllegalArgumentException because the null version is unexpected version class) -- 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 month

1
0
0 / 0

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

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3737?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3737: -------------------------------- Labels: 620 (was: ) > 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 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3704) StateTransfer's PutKeyValueCommand may trigger remote get

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3704?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3704: ------------------------------------- [~rvansa] does this affect the consistency in any way? or is just un-needed work that happen. If the later, then severity should be reduced. > StateTransfer's PutKeyValueCommand may trigger remote get > --------------------------------------------------------- > > Key: ISPN-3704 > URL: https://issues.jboss.org/browse/ISPN-3704 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Mircea Markus > Priority: Critical > > In TX mode with write skew check on, ST executing puts may trigger a remote get. > The condition in TxDistributionInterceptor.handleTxWriteCommand should probably be switched from > {code} > if (ctx.isOriginLocal() && !skipRemoteGet || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command)) > remoteGetBeforeWrite(ctx, command, recipientGenerator); > {code} > to > {code} > if (!skipRemoteGet && (ctx.isOriginLocal() || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command))) > remoteGetBeforeWrite(ctx, command, recipientGenerator); > {code} > EDIT: > I have also registered a situation where the Prepare/Commit command was executed remotely from within the ST because the topology has changed during the remote get. This should be avoided as well. -- 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 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3767) MassIndexer breaks search feature with one node cluster

by Romain Pelisse (JIRA)

[ https://issues.jboss.org/browse/ISPN-3767?page=com.atlassian.jira.plugin.... ] Romain Pelisse updated ISPN-3767: --------------------------------- Description: Hi, Trying to cope with the extreme slowliness of put() operation with indexing [1], I've tried to use the MassIndexer, to create the index AFTER adding all the data in the grid. This actually works pretty well, but, when running in a "single node" grid, it "breaks" the search, which always returns 0 result to any kind of query. I've modified one of the test suite of InfiniSpan to reproduce the issue: https://github.com/rpelisse/infinispan/tree/mass-indexer-breaks-search-wi... Once this branch is checked out, just run : $ cd ./query $ mvn clean -Dtest=org.infinispan.query.distributed.DistributedMassIndexingTest test Note: MassIndexer being implemented using the Map/Reduce algorithm, it requires to run within a cluster (ie several instances of ISPN). [1] http://stackoverflow.com/questions/10090361/infinispan-very-slow-for-load... If run within a single node cluster, the MassIndexer was: Hi, Trying to cope with the extreme slowliness of put() operation with indexing [1], I've tried to use the MassIndexer, to create the index AFTER adding all the data in the grid. This actually works pretty well, but, when running in a "single node" grid, it "breaks" the search, which always returns 0 result to any kind of query. I've modified one of the test suite of InfiniSpan to reproduce the issue: https://github.com/rpelisse/infinispan/tree/mass-indexer-breaks-search-wi... Note: MassIndexer being implemented using the Map/Reduce algorithm, it requires to run within a cluster (ie several instances of ISPN). [1] http://stackoverflow.com/questions/10090361/infinispan-very-slow-for-load... If run within a single node cluster, the MassIndexer > MassIndexer breaks search feature with one node cluster > ------------------------------------------------------- > > Key: ISPN-3767 > URL: https://issues.jboss.org/browse/ISPN-3767 > Project: Infinispan > Issue Type: Bug > Reporter: Romain Pelisse > Assignee: Alan Field > Priority: Minor > > Hi, > Trying to cope with the extreme slowliness of put() operation with indexing [1], I've tried to use the MassIndexer, to create the index AFTER adding all the data in the grid. This actually works pretty well, but, when running in a "single node" grid, it "breaks" the search, which always returns 0 result to any kind of query. > I've modified one of the test suite of InfiniSpan to reproduce the issue: > https://github.com/rpelisse/infinispan/tree/mass-indexer-breaks-search-wi... > Once this branch is checked out, just run : > $ cd ./query > $ mvn clean -Dtest=org.infinispan.query.distributed.DistributedMassIndexingTest test > Note: MassIndexer being implemented using the Map/Reduce algorithm, it requires to run within a cluster (ie several instances of ISPN). > [1] http://stackoverflow.com/questions/10090361/infinispan-very-slow-for-load... > If run within a single node cluster, the MassIndexer -- 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 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3767) MassIndexer breaks search feature with one node cluster

by Romain Pelisse (JIRA)

[ https://issues.jboss.org/browse/ISPN-3767?page=com.atlassian.jira.plugin.... ] Romain Pelisse updated ISPN-3767: --------------------------------- Description: Hi, Trying to cope with the extreme slowliness of put() operation with indexing [1], I've tried to use the MassIndexer, to create the index AFTER adding all the data in the grid. This actually works pretty well, but, when running in a "single node" grid, it "breaks" the search, which always returns 0 result to any kind of query. I've modified one of the test suite of InfiniSpan to reproduce the issue: https://github.com/rpelisse/infinispan/tree/mass-indexer-breaks-search-wi... Note: MassIndexer being implemented using the Map/Reduce algorithm, it requires to run within a cluster (ie several instances of ISPN). [1] http://stackoverflow.com/questions/10090361/infinispan-very-slow-for-load... If run within a single node cluster, the MassIndexer Assignee: Alan Field (was: Romain Pelisse) > MassIndexer breaks search feature with one node cluster > ------------------------------------------------------- > > Key: ISPN-3767 > URL: https://issues.jboss.org/browse/ISPN-3767 > Project: Infinispan > Issue Type: Bug > Reporter: Romain Pelisse > Assignee: Alan Field > Priority: Minor > > Hi, > Trying to cope with the extreme slowliness of put() operation with indexing [1], I've tried to use the MassIndexer, to create the index AFTER adding all the data in the grid. This actually works pretty well, but, when running in a "single node" grid, it "breaks" the search, which always returns 0 result to any kind of query. > I've modified one of the test suite of InfiniSpan to reproduce the issue: > https://github.com/rpelisse/infinispan/tree/mass-indexer-breaks-search-wi... > Note: MassIndexer being implemented using the Map/Reduce algorithm, it requires to run within a cluster (ie several instances of ISPN). > [1] http://stackoverflow.com/questions/10090361/infinispan-very-slow-for-load... > If run within a single node cluster, the MassIndexer -- 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 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3669) Upgrade infinispan quickstarts to work with ISPN 6.0

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3669?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3669: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan-quickstart/pull/12 > Upgrade infinispan quickstarts to work with ISPN 6.0 > ---------------------------------------------------- > > Key: ISPN-3669 > URL: https://issues.jboss.org/browse/ISPN-3669 > Project: Infinispan > Issue Type: Task > Reporter: Martin Gencur > Assignee: Pedro Ruivo > Priority: Blocker > Labels: 620 > Fix For: 6.1.0.Final > > > The infinispan-quickstart (https://github.com/infinispan/infinispan-quickstart) should be up-to-date for ISPN 6.0. > Also because Getting started guide is referring to them quite a lot. -- 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 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3736) Backport to 5.2.x for EAP 6.3

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-3736?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on ISPN-3736: ------------------------------------ [~mgencur] Do you know if ISPN-3635 affects 5.2.x? On 5.2.x the lock owner is always the coordinator (as I understand it). > Backport to 5.2.x for EAP 6.3 > ----------------------------- > > Key: ISPN-3736 > URL: https://issues.jboss.org/browse/ISPN-3736 > Project: Infinispan > Issue Type: Task > Affects Versions: 5.2.7.Final > Reporter: Paul Ferraro > Assignee: Mircea Markus > Fix For: 5.2.8.Final > > > This JIRA will track the issues that need to be backported to the 5.2.x branch for EAP 6.3. -- 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 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3767) MassIndexer breaks search feature with one node cluster

by Romain Pelisse (JIRA)

[ https://issues.jboss.org/browse/ISPN-3767?page=com.atlassian.jira.plugin.... ] Romain Pelisse updated ISPN-3767: --------------------------------- Priority: Minor (was: Major) Assignee: Romain Pelisse (was: Mircea Markus) > MassIndexer breaks search feature with one node cluster > ------------------------------------------------------- > > Key: ISPN-3767 > URL: https://issues.jboss.org/browse/ISPN-3767 > Project: Infinispan > Issue Type: Bug > Reporter: Romain Pelisse > Assignee: Romain Pelisse > Priority: Minor > -- 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 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2013