July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3296) Total Order check list

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3296: --------------------------------- Summary: Total Order check list Key: ISPN-3296 URL: https://issues.jboss.org/browse/ISPN-3296 Project: Infinispan Issue Type: Task Reporter: Pedro Ruivo Assignee: Pedro Ruivo Priority: Critical Issues found in Cloud-TM. Check if they happen here and create a JIRA for each of them * IgnoreExtraResponseFilter is not needed anymore. * missing argument log message * TimeoutException, when happens, it is ignored and the transaction is processed normally * TimeoutException can block the total order chain (all system is blocked!) * port the testTimeoutCleanup from cloudtm to master -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3126) PUT performance degradation in Infinispan 5.3

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-3126?page=com.atlassian.jira.plugin.... ] Martin Gencur resolved ISPN-3126. --------------------------------- Resolution: Rejected This is not a bug. The performance regression was caused by incorrect JGroups settings. > PUT performance degradation in Infinispan 5.3 > --------------------------------------------- > > Key: ISPN-3126 > URL: https://issues.jboss.org/browse/ISPN-3126 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.3.0.Beta2, 5.3.0.CR1 > Reporter: Mircea Markus > Assignee: Martin Gencur > Priority: Critical > Fix For: 6.0.0.Final > > -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3295) Add a warning message to the log if the old bundler is enabled

by Alan Field (JIRA)

[ https://issues.jboss.org/browse/ISPN-3295?page=com.atlassian.jira.plugin.... ] Alan Field updated ISPN-3295: ----------------------------- Description: In JGroups 3.3, the new bundler is the default. If the old bundler is enabled (i.e. UDP.bundler_type="old") then Infinispan performance is adversely affected. Infinispan should warn if the old bundler is enabled to notify users of this situation. (was: In JGroups 3.3, the new bundler is the default. If the old bundler is enabled (i.e. UDP.bundler_type="old") then Infinispan performance is adversely affected. JGroups should warn if the old bundler is enabled to notify users of this situation.) > Add a warning message to the log if the old bundler is enabled > -------------------------------------------------------------- > > Key: ISPN-3295 > URL: https://issues.jboss.org/browse/ISPN-3295 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final > Reporter: Alan Field > Assignee: Bela Ban > > In JGroups 3.3, the new bundler is the default. If the old bundler is enabled (i.e. UDP.bundler_type="old") then Infinispan performance is adversely affected. Infinispan should warn if the old bundler is enabled to notify users of this situation. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3295) Add a warning message to the log if the old bundler is enabled

by Alan Field (JIRA)

[ https://issues.jboss.org/browse/ISPN-3295?page=com.atlassian.jira.plugin.... ] Alan Field moved JGRP-1650 to ISPN-3295: ---------------------------------------- Project: Infinispan (was: JGroups) Key: ISPN-3295 (was: JGRP-1650) Issue Type: Bug (was: Enhancement) Workflow: GIT Pull Request workflow (was: jira) Affects Version/s: 5.3.0.Final (was: 3.3) > Add a warning message to the log if the old bundler is enabled > -------------------------------------------------------------- > > Key: ISPN-3295 > URL: https://issues.jboss.org/browse/ISPN-3295 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final > Reporter: Alan Field > Assignee: Bela Ban > > In JGroups 3.3, the new bundler is the default. If the old bundler is enabled (i.e. UDP.bundler_type="old") then Infinispan performance is adversely affected. JGroups should warn if the old bundler is enabled to notify users of this situation. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3291) Component registry should always use an appropriate classloader

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3291?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3291: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Component registry should always use an appropriate classloader > --------------------------------------------------------------- > > Key: ISPN-3291 > URL: https://issues.jboss.org/browse/ISPN-3291 > Project: Infinispan > Issue Type: Bug > Components: Core API > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Critical > Fix For: 6.0.0.Alpha1 > > > Since the commons split, ReflectionUtil cannot find classes outside of its containing JAR in a modular classloader environment (i.e. server). -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3294) Update server so that it compiles against commons

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3294?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3294: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Update server so that it compiles against commons > ------------------------------------------------- > > Key: ISPN-3294 > URL: https://issues.jboss.org/browse/ISPN-3294 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 6.0.0.Alpha1 > > -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3289) PutForExternalRead should only write the value on the originator once

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3289?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3289: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1947 > PutForExternalRead should only write the value on the originator once > --------------------------------------------------------------------- > > Key: ISPN-3289 > URL: https://issues.jboss.org/browse/ISPN-3289 > Project: Infinispan > Issue Type: Bug > Reporter: Dan Berindei > Assignee: William Burns > Fix For: 6.0.0.Final > > > putForExternalRead behaves as an asynchronous, non-transactional write operation even in tx caches, and as such it uses lock delegation. > Let's say we have a cluster with two nodes: [A, B], and a key k with owners(k) = [A, B]. > If B is the originator of a PFER(k, v) operation, the command is first executed locally on B, then it is invoked asynchronously on the primary owner A, and A invokes it asynchronously on B (because of the FORCE_ASNCHRONOUS flag). > For regular non-tx write operations, the entry k=v is only written to the data container on B during the second invocation. For PFER, however, the entry is written twice: once during each execution. > This causes random failures in {{PutForExternalRead*Test.testNoOpWhenKeyPresent}}, because the test assumes that the PFER finished once the entry was written once on each owner. > Arguably the fact that the primary owner forwards the PFER command asynchronously is also a problem, because the put command will write the value on B without holding a lock on A, the primary owner. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3126) PUT performance degradation in Infinispan 5.3

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3126?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3126: ----------------------------------------------- Alan Field <afield(a)redhat.com> made a comment on [bug 965220|https://bugzilla.redhat.com/show_bug.cgi?id=965220] The performance degradation is not a bug, but JGroups should warn that the old bundler is enabled. I'll enter a new JIRA for that. > PUT performance degradation in Infinispan 5.3 > --------------------------------------------- > > Key: ISPN-3126 > URL: https://issues.jboss.org/browse/ISPN-3126 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.3.0.Beta2, 5.3.0.CR1 > Reporter: Mircea Markus > Assignee: Martin Gencur > Priority: Critical > Fix For: 6.0.0.Final > > -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3126) PUT performance degradation in Infinispan 5.3

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3126?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3126: ----------------------------------------------- Alan Field <afield(a)redhat.com> changed the Status of [bug 965220|https://bugzilla.redhat.com/show_bug.cgi?id=965220] from NEW to CLOSED > PUT performance degradation in Infinispan 5.3 > --------------------------------------------- > > Key: ISPN-3126 > URL: https://issues.jboss.org/browse/ISPN-3126 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.3.0.Beta2, 5.3.0.CR1 > Reporter: Mircea Markus > Assignee: Martin Gencur > Priority: Critical > Fix For: 6.0.0.Final > > -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3281) Deadlock in non-transactional caches during rebalance

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3281?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3281: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1946 > Deadlock in non-transactional caches during rebalance > ----------------------------------------------------- > > Key: ISPN-3281 > URL: https://issues.jboss.org/browse/ISPN-3281 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency, State transfer > Affects Versions: 5.3.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 6.0.0.Final > > > Say we have a cache with node A and node B joins. The cache topology id is 1, primary_owner(k) = A in the current CH and primary_owner(k) = B in the pending CH. > 1. Node A starts a put(k, v) command during the rebalance. It thinks it's the primary owner, so it acquires the lock locally and it forwards the command to B. > 2. B installs topology 2, primary_owner(k) = B in the current CH, and there is no pending CH. > 3. B receives the put(k, v) command from A. It thinks it's the primary owner, so it acquires the lock locally and it forwards the command to A. > 4. A receives the put(k, v) command from B. Again it thinks it's the primary owner and tries to acquire the lock locally, but it times out because the lock is held by another thread (from step 1). > I think it may be enough to update the topology id in the put(k, v) command on node B, before forwarding it back to A. That way, the command will block on node A until topology 2 is installed, and it won't try to lock the key again. -- 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, 9 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 July 2013