April 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2813) DummyTransaction do not commit is last resource transaction is read-only

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2813?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2813: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3379 > DummyTransaction do not commit is last resource transaction is read-only > ------------------------------------------------------------------------ > > Key: ISPN-2813 > URL: https://issues.jboss.org/browse/ISPN-2813 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.1.6.FINAL > Reporter: Vitalii Tymchyshyn > Assignee: Pedro Ruivo > Priority: Minor > Fix For: 7.2.0.CR1 > > > Currently HEAD DummyTransaction.java has this code: > ... > for (XAResource res : resources) { > try { > int prepareStatus = res.prepare(xid); > transaction.setPrepareStatus(prepareStatus); > ... > This means that transaction gets prepare status of the last resource (cache in case of infinispan) enlisted. > Also it has next code: > ... > if (transaction.getPrepareStatus() == XAResource.XA_RDONLY) { > log.debug("This is a read-only tx"); > } else { > ... Do commit ... > ... > This means that if last resource returned XA_RDONLY (e.g. when on last cache only get was performed) all other resources are not committed. > For me this results in locks held indefinitely and transaction leak. > Correct would be to remember prepare status per-resource and act accordinly. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2813) DummyTransaction do not commit is last resource transaction is read-only

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2813?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2813: ------------------------------ Fix Version/s: 7.2.0.CR1 > DummyTransaction do not commit is last resource transaction is read-only > ------------------------------------------------------------------------ > > Key: ISPN-2813 > URL: https://issues.jboss.org/browse/ISPN-2813 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.1.6.FINAL > Reporter: Vitalii Tymchyshyn > Assignee: Pedro Ruivo > Priority: Minor > Fix For: 7.2.0.CR1 > > > Currently HEAD DummyTransaction.java has this code: > ... > for (XAResource res : resources) { > try { > int prepareStatus = res.prepare(xid); > transaction.setPrepareStatus(prepareStatus); > ... > This means that transaction gets prepare status of the last resource (cache in case of infinispan) enlisted. > Also it has next code: > ... > if (transaction.getPrepareStatus() == XAResource.XA_RDONLY) { > log.debug("This is a read-only tx"); > } else { > ... Do commit ... > ... > This means that if last resource returned XA_RDONLY (e.g. when on last cache only get was performed) all other resources are not committed. > For me this results in locks held indefinitely and transaction leak. > Correct would be to remember prepare status per-resource and act accordinly. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5368) Out of order events produced when using the MassIndexer with async backend

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5368?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5368: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.2.0.CR1 7.2.0.Final Resolution: Done > Out of order events produced when using the MassIndexer with async backend > -------------------------------------------------------------------------- > > Key: ISPN-5368 > URL: https://issues.jboss.org/browse/ISPN-5368 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.2.0.Beta2, 7.1.1.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 7.2.0.CR1, 7.2.0.Final > > > When using async indexing backend on DIST caches with shared index (InfinispanIndexManager), the MassIndexer fails to re-index all the entries, if it is run from a node that is not > the indexing master. > Normally the operation sequence of the MassIndexer in the above configuration, for a two node cluster is: > * Purge the index > * Send index job to node A and to node B > * Flush > Given the backend is async, all index commands are sent to the master RPC-wise asynchronously, and so a reorder can occur and produce like: > * Send index job to node A > * Purge > * Send index job to node B > * Flush > Causing previously re-indexed entries to be wiped -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5368) Out of order events produced when using the MassIndexer with async backend

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5368?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5368: ----------------------------------- Affects Version/s: 7.1.1.Final 7.2.0.Beta2 > Out of order events produced when using the MassIndexer with async backend > -------------------------------------------------------------------------- > > Key: ISPN-5368 > URL: https://issues.jboss.org/browse/ISPN-5368 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.2.0.Beta2, 7.1.1.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 7.2.0.CR1, 7.2.0.Final > > > When using async indexing backend on DIST caches with shared index (InfinispanIndexManager), the MassIndexer fails to re-index all the entries, if it is run from a node that is not > the indexing master. > Normally the operation sequence of the MassIndexer in the above configuration, for a two node cluster is: > * Purge the index > * Send index job to node A and to node B > * Flush > Given the backend is async, all index commands are sent to the master RPC-wise asynchronously, and so a reorder can occur and produce like: > * Send index job to node A > * Purge > * Send index job to node B > * Flush > Causing previously re-indexed entries to be wiped -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5351) read()ing protected Attributes should support user-supplied copying methods

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5351?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5351: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.2.0.CR1 Resolution: Done > read()ing protected Attributes should support user-supplied copying methods > --------------------------------------------------------------------------- > > Key: ISPN-5351 > URL: https://issues.jboss.org/browse/ISPN-5351 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.2.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.CR1 > > > Cloning a configuration attribute sometimes is not enough. For example when dealing with collections and immutable types we need to overcome the following: > Caused by: java.lang.UnsupportedOperationException > at org.infinispan.commons.util.Immutables$ImmutableTypedProperties.put(Immutables.java:622) > at org.infinispan.configuration.cache.IndexingConfigurationBuilder.setProperty(IndexingConfigurationBuilder.java:130) > at org.infinispan.configuration.cache.IndexingConfigurationBuilder.addProperty(IndexingConfigurationBuilder.java:107) > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5351) read()ing protected Attributes should support user-supplied copying methods

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5351?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5351: ----------------------------------- Affects Version/s: 7.2.0.Beta2 > read()ing protected Attributes should support user-supplied copying methods > --------------------------------------------------------------------------- > > Key: ISPN-5351 > URL: https://issues.jboss.org/browse/ISPN-5351 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.2.0.Beta2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.CR1 > > > Cloning a configuration attribute sometimes is not enough. For example when dealing with collections and immutable types we need to overcome the following: > Caused by: java.lang.UnsupportedOperationException > at org.infinispan.commons.util.Immutables$ImmutableTypedProperties.put(Immutables.java:622) > at org.infinispan.configuration.cache.IndexingConfigurationBuilder.setProperty(IndexingConfigurationBuilder.java:130) > at org.infinispan.configuration.cache.IndexingConfigurationBuilder.addProperty(IndexingConfigurationBuilder.java:107) > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5019) After coordinator change, cache topologies should be installed in parallel

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5019?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5019: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1195565|https://bugzilla.redhat.com/show_bug.cgi?id=1195565] from NEW to ASSIGNED > After coordinator change, cache topologies should be installed in parallel > -------------------------------------------------------------------------- > > Key: ISPN-5019 > URL: https://issues.jboss.org/browse/ISPN-5019 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.2.0.CR1 > > > When the coordinator crashes, the new coordinator has to recover the cache topologies from all the nodes in the cluster and install updated topologies for all the caches. This is done on a single thread, and it can take a long time when there are a lot of caches. > We should be accelerate this by doing the topology installation on separate threads. However, we have to be careful with the async transport pool, because {{executeOnClusterAsync}} actually needs to spawn a new thread in the same pool. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4621) MassIndexer does not work on replicated cache (with local index)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4621?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4621: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1208162|https://bugzilla.redhat.com/show_bug.cgi?id=1208162] from NEW to ASSIGNED > MassIndexer does not work on replicated cache (with local index) > ---------------------------------------------------------------- > > Key: ISPN-4621 > URL: https://issues.jboss.org/browse/ISPN-4621 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 7.0.0.Alpha5 > Reporter: Radim Vansa > Assignee: Gustavo Fernandes > Priority: Critical > Fix For: 7.1.0.CR2 > > Attachments: ReplRamMassIndexingTest.java > > > MassIndexer indexes only entries that are primary on each node: other entries are missing when index is rebuilt. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5350) Use DSL based filters with Hot Rod event listeners

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5350?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5350: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1211944|https://bugzilla.redhat.com/show_bug.cgi?id=1211944] from NEW to POST > Use DSL based filters with Hot Rod event listeners > -------------------------------------------------- > > Key: ISPN-5350 > URL: https://issues.jboss.org/browse/ISPN-5350 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Affects Versions: 7.2.0.Beta2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.CR1, 7.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5349) Use DSL based filters with local and clustered event listeners

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5349?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5349: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1211944|https://bugzilla.redhat.com/show_bug.cgi?id=1211944] from NEW to POST > Use DSL based filters with local and clustered event listeners > -------------------------------------------------------------- > > Key: ISPN-5349 > URL: https://issues.jboss.org/browse/ISPN-5349 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 7.2.0.Beta2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.CR1, 7.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 12 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 April 2015