July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2465) Rollback sent twice in certain situations

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2465?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2465: ------------------------------------- reducing prio to Minor as this doesn't have any impact on functionality but adds some unneeded network calls on rollback. > Rollback sent twice in certain situations > ----------------------------------------- > > Key: ISPN-2465 > URL: https://issues.jboss.org/browse/ISPN-2465 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.1.8.Final, 5.2.0.Final > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Minor > Fix For: 6.0.0.Final > > > If a prepare files e.g. due to a lock timeout, the initiating node sends a RollbackCommand before giving control back to the TransactionManager. The transaction manager might decide to invoke a rollback as well on the Synchrnization or XAResouce object, causing the rollback to be multicasted twice. This is not critical as the second Rollback is practically ignored, but unnecessary. -- 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-2465) Rollback sent twice in certain situations

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2465?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2465: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Rollback sent twice in certain situations > ----------------------------------------- > > Key: ISPN-2465 > URL: https://issues.jboss.org/browse/ISPN-2465 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.1.8.Final, 5.2.0.Final > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Minor > > If a prepare files e.g. due to a lock timeout, the initiating node sends a RollbackCommand before giving control back to the TransactionManager. The transaction manager might decide to invoke a rollback as well on the Synchrnization or XAResouce object, causing the rollback to be multicasted twice. This is not critical as the second Rollback is practically ignored, but unnecessary. -- 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-2678) Security needs to be implemented for HotRod

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2678?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2678: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Security needs to be implemented for HotRod > ------------------------------------------- > > Key: ISPN-2678 > URL: https://issues.jboss.org/browse/ISPN-2678 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration, Server > Reporter: Joel Tosi > Assignee: Mircea Markus > Labels: security > > Breakdown of ISPN-143 - https://issues.jboss.org/browse/ISPN-143 > This is implementing security for the HotRod client -- 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-1823) Revisit internal collections used and replace with custom, high performance constructs

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1823?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1823: -------------------------------- Priority: Minor (was: Major) > Revisit internal collections used and replace with custom, high performance constructs > -------------------------------------------------------------------------------------- > > Key: ISPN-1823 > URL: https://issues.jboss.org/browse/ISPN-1823 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Affects Versions: 5.1.0.FINAL > Reporter: Manik Surtani > Assignee: Manik Surtani > Priority: Minor > Labels: gc, memory, performance > > Most JDK collections are too inefficient for internal use, such as within contexts, cache transactions, etc. -- 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-2465) Rollback sent twice in certain situations

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2465?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2465: -------------------------------- Issue Type: Bug (was: Feature Request) > Rollback sent twice in certain situations > ----------------------------------------- > > Key: ISPN-2465 > URL: https://issues.jboss.org/browse/ISPN-2465 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.1.8.Final, 5.2.0.Final > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > > If a prepare files e.g. due to a lock timeout, the initiating node sends a RollbackCommand before giving control back to the TransactionManager. The transaction manager might decide to invoke a rollback as well on the Synchrnization or XAResouce object, causing the rollback to be multicasted twice. This is not critical as the second Rollback is practically ignored, but unnecessary. -- 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-2465) Rollback sent twice in certain situations

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2465?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2465: -------------------------------- Priority: Minor (was: Major) > Rollback sent twice in certain situations > ----------------------------------------- > > Key: ISPN-2465 > URL: https://issues.jboss.org/browse/ISPN-2465 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.1.8.Final, 5.2.0.Final > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Minor > Fix For: 6.0.0.Final > > > If a prepare files e.g. due to a lock timeout, the initiating node sends a RollbackCommand before giving control back to the TransactionManager. The transaction manager might decide to invoke a rollback as well on the Synchrnization or XAResouce object, causing the rollback to be multicasted twice. This is not critical as the second Rollback is practically ignored, but unnecessary. -- 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-1823) Revisit internal collections used and replace with custom, high performance constructs

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1823?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1823: -------------------------------- Priority: Major (was: Critical) > Revisit internal collections used and replace with custom, high performance constructs > -------------------------------------------------------------------------------------- > > Key: ISPN-1823 > URL: https://issues.jboss.org/browse/ISPN-1823 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Affects Versions: 5.1.0.FINAL > Reporter: Manik Surtani > Assignee: Manik Surtani > Labels: gc, memory, performance > > Most JDK collections are too inefficient for internal use, such as within contexts, cache transactions, etc. -- 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-1823) Revisit internal collections used and replace with custom, high performance constructs

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1823?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-1823: ------------------------------------- I've reduced the priority to minor as this is an optimisation and I'm not aware of any analysis to indicate that this is critically needed. > Revisit internal collections used and replace with custom, high performance constructs > -------------------------------------------------------------------------------------- > > Key: ISPN-1823 > URL: https://issues.jboss.org/browse/ISPN-1823 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Affects Versions: 5.1.0.FINAL > Reporter: Manik Surtani > Assignee: Manik Surtani > Labels: gc, memory, performance > > Most JDK collections are too inefficient for internal use, such as within contexts, cache transactions, etc. -- 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-820) Resolve {@link} links in configuration reference

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-820?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-820: ------------------------------- Fix Version/s: (was: 6.0.0.Final) > Resolve {@link} links in configuration reference > ------------------------------------------------- > > Key: ISPN-820 > URL: https://issues.jboss.org/browse/ISPN-820 > Project: Infinispan > Issue Type: Feature Request > Reporter: Galder Zamarreño > Assignee: Pete Muir > > Currently configuration reference documentation does not resolve {@link} links. > It'd be nice if it'd point to the javadoc of the corresponding class if available! > Examples: > - Fully qualified class name of a class that looks up a reference to a {@link javax.transaction.TransactionManager}. The default provided is capable of locating the default TransactionManager in most popular Java EE systems, using a JNDI lookup. (Javadoc) > - Fully qualified name of the class that the configured {@link org.infinispan.marshall.Externalizer} can marshall/unmarshall. Establishing the link between type marshalled and {@link org.infinispan.marshall.Externalizer} implementations enables users to provide their own marshalling mechanisms even for classes which they cannot modify or extend. (Javadoc) -- 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-833) Revisit cache name predefinition limitation for cache servers

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-833?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-833: ------------------------------- Fix Version/s: (was: 6.0.0.Final) > Revisit cache name predefinition limitation for cache servers > ------------------------------------------------------------- > > Key: ISPN-833 > URL: https://issues.jboss.org/browse/ISPN-833 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > There're are two primary reasons why Infinispan servers require predefined caches to be started up on startup, and do not allow invocations to undefined caches: > 1. Concurrent cache startups were resulting in NPEs (ISPN-635) - This is already solved since the 4.2.x days. > 2. Infinispan has issues dealing with asymmetric clusters (ISPN-658). > Once these two issues have been resolved, revisit the limitation. -- 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