September 2012 - infinispan-issues

[JBoss JIRA] (ISPN-2348) Killing remote bridge end results in unrecoverable SuspectExceptions

by Erik Salter (JIRA)

Erik Salter created ISPN-2348: --------------------------------- Summary: Killing remote bridge end results in unrecoverable SuspectExceptions Key: ISPN-2348 URL: https://issues.jboss.org/browse/ISPN-2348 Project: Infinispan Issue Type: Bug Components: Cross-Site Replication Affects Versions: 5.2.0.Alpha4 Reporter: Erik Salter Assignee: Mircea Markus During sync replication testing, I killed the backup site's bridge end connection. Subsequent writes were unable to continue. See logs at: http://dl.dropbox.com/u/50401510/5.2.0.ALPHA4/xsite_syncKillCoord/10.30.1... http://dl.dropbox.com/u/50401510/5.2.0.ALPHA4/xsite_syncKillCoord/10.30.1... http://dl.dropbox.com/u/50401510/5.2.0.ALPHA4/xsite_syncKillCoord/10.30.1... {den-dg1 (10.30.12.156), den-dg-2 (10.30.12.157), and den-dg3 (10.30.12.158)} were backups for another cluster. The node den-dg2 was the RELAY2 coordinator. It was then killed. The cluster processed the view change, but the newly elected coordinator kept broadcasting commands to include den-dg2. For instance: 2012-09-26 15:09:49,123 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (Incoming-10,erm-bridge,_den-dg3-27305:den) den-dg3-27305(den) broadcasting call PrepareCommand {modifications=[PutKeyValueCommand{key=8a93b36d-9519-4886-9527-115b8394ec90, value=..., flags=[IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, lifespanMillis=-1, maxIdleTimeMillis=-1}], onePhaseCommit=false, gtx=GlobalTransaction:<den-dg3-27305(den)>:196:local, cacheName='ermSession', topologyId=4} to recipient list [den-dg2-7712(den), den-dg3-27305(den)] -- 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, 6 months

2
3
0 / 0

[JBoss JIRA] (ISPN-2198) Cluster with non-shared JDBC cache store has too much entries after node failure

by Radim Vansa (JIRA)

Radim Vansa created ISPN-2198: --------------------------------- Summary: Cluster with non-shared JDBC cache store has too much entries after node failure Key: ISPN-2198 URL: https://issues.jboss.org/browse/ISPN-2198 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.1.5.FINAL Reporter: Radim Vansa In resilience test with 4-node cluster where one node is killed a weird situation appears. Before the node kill have this number of entries: 210602;215820;209400;203038 = 838860 entries After the kill the number of entries changes for a while: 210602;null;209400;203038 250602;null;269400;243038 290602;null;269400;273038 300602;null;289400;293038 300602;null;289400;293038 321218;null;296035;293038 But then it stabilizes on 326899;null;305039;314165 = 946103 entries When the node02 is restarted it complains about duplicit entries: ERROR [org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore] (OOB-124,null) ISPN008024: Error while storing string key to database; key: '8Az4Ia2V5NzYzNDI=', buffer size of value: 1050 bytes: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '?8Az4Ia2V5NzYzNDI=' for key 'PRIMARY' Is this a bug or wrong configuration? Here is an excerpt from configuration (sorry for no formatting): <distributed-cache batching="false" indexing="NONE" l1-lifespan="0" mode="SYNC" name="memcachedCache" owners="2" remote-timeout="60000" start="EAGER" virtual-nodes="512"> <locking acquire-timeout="3000" concurrency-level="1000" isolation="REPEATABLE_READ" striping="false"/> <transaction mode="NONE"/> <state-transfer enabled="true" timeout="600000"/> <eviction max-entries="-1" strategy="NONE"/> <string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" passivation="false" preload="false" purge="true" shared="false"> <property name="databaseType">MYSQL</property> <string-keyed-table prefix="node01"> <id-column name="id" type="VARCHAR(100)"/> <data-column name="value" type="BLOB(1200)"/> </string-keyed-table> </string-keyed-jdbc-store> </distributed-cache> -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

4
19
0 / 0

[JBoss JIRA] Created: (ISPN-767) Make deadlock detection run over multiple caches

by Mircea Markus (JIRA)

Make deadlock detection run over multiple caches ------------------------------------------------ Key: ISPN-767 URL: https://jira.jboss.org/browse/ISPN-767 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.2.0.Final right now deadlock detection runs on a per cache basis. Eg. following deadlock won't be detected: - N1,N2 two nodes, A and B are cache running on each of them. tx1 running on N1: N1.A.put(k1); N1.B.put(k2) tx2 running in N2: N2.B.put(k2); N2.A.put(k1) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-1419) Clean up ConfigurationOverrides to match what 5.1 supports

by Marius Bogoevici (JIRA)

Clean up ConfigurationOverrides to match what 5.1 supports ---------------------------------------------------------- Key: ISPN-1419 URL: https://issues.jboss.org/browse/ISPN-1419 Project: Infinispan Issue Type: Bug Components: Spring integration Affects Versions: 5.1.0.ALPHA2 Reporter: Marius Bogoevici Assignee: Marius Bogoevici Fix For: 5.1.0.BETA1 Currently, ConfigurationOverrides is accessing Configuration directly through a series of deprecated methods. Make this fully compatible with Infinispan 5.1 and use FluentConfiguration instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

4
13
0 / 0

[JBoss JIRA] Created: (ISPN-1068) Add usage support similar to the one included in Spring Data

by Marius Bogoevici (JIRA)

Add usage support similar to the one included in Spring Data ------------------------------------------------------------ Key: ISPN-1068 URL: https://issues.jboss.org/browse/ISPN-1068 Project: Infinispan Issue Type: Feature Request Reporter: Marius Bogoevici Assignee: Manik Surtani ... i.e. InfinispanTemplate/InfinispanCallback -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

5
20
0 / 0

[JBoss JIRA] (ISPN-2020) MarshalledValues to not compact eagerly

by Manik Surtani (JIRA)

Manik Surtani created ISPN-2020: ----------------------------------- Summary: MarshalledValues to not compact eagerly Key: ISPN-2020 URL: https://issues.jboss.org/browse/ISPN-2020 Project: Infinispan Issue Type: Feature Request Components: Marshalling Affects Versions: 5.1.4.FINAL Reporter: Manik Surtani Assignee: Galder Zamarreño Fix For: 5.1.x, 5.2.0.ALPHA1, 5.2.0.FINAL Marshalled values currently get compacted aggressively, limiting usability as a form of class loader isolation. E.g., Node 1: put(k, v) results in v being wrapped in a MarshalledValue, the instance field being set, the raw field being generated when serialization is needed, and as the put call returns, the raw field is un-set. This is fine for the most part, except when state transfer kicks in, and the entry needs to be transferred elsewhere. The instance may not be serialized since an application specific class loader may not be available at this time. This proposal is to add the following: 1. A new configuration option, {{eagerCompacting}}, defaulting to {{true}} (current behaviour). 2. If set to false, the raw representation is kept around, and can be reused, effectively working around the class loader problem. 3. The drawback here would be the additional memory needed to store the second reference on the originator, but the benefit of not having to serialize as often should offset this. Compacting then can still happen on the originator by manually triggering the {{cache#compact()}} API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

3
8
0 / 0

[JBoss JIRA] (ISPN-1439) Async store needs redesigning to support injected executors

by Galder Zamarreño (Created) (JIRA)

Async store needs redesigning to support injected executors ----------------------------------------------------------- Key: ISPN-1439 URL: https://issues.jboss.org/browse/ISPN-1439 Project: Infinispan Issue Type: Enhancement Components: Configuration, Loaders and Stores Reporter: Galder Zamarreño Assignee: Sanne Grinovero Fix For: 5.2.0.FINAL The CoalescedAsyncStore design is pretty complex and is designed around AsyncStore being able to control the lifecycle of the async store coordinator and processor executors. A re-design of the async store is needed to enable central management of these executors, in such way that the NamedExecutorFactory can start with the right parameters (take in account that multiple caches could be configured with an async store), and the shutdown procedure can be correctly executed by the cache manager. The async store's coalesced logic makes this a fairly complex task, particularly since the introduction of Sanne's changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

3
3
0 / 0

[JBoss JIRA] (ISPN-1762) Add tests for configuration options that can change at runtime

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-1762: -------------------------------------- Summary: Add tests for configuration options that can change at runtime Key: ISPN-1762 URL: https://issues.jboss.org/browse/ISPN-1762 Project: Infinispan Issue Type: Bug Components: Configuration Reporter: Galder Zamarreño Assignee: Manik Surtani Fix For: 5.2.0.FINAL There are no test for those configuration options that can be changed at runtime. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-1353) Cluster wide atomic integer(should be unique and incremental between cache restarts) and atomic id(uuid+unique cache node id) generation

by Magnus Magnus (JIRA)

Cluster wide atomic integer(should be unique and incremental between cache restarts) and atomic id(uuid+unique cache node id) generation ---------------------------------------------------------------------------------------------------------------------------------------- Key: ISPN-1353 URL: https://issues.jboss.org/browse/ISPN-1353 Project: Infinispan Issue Type: Feature Request Reporter: Magnus Magnus Assignee: Manik Surtani Fix For: 5.1.0.FINAL, 5.2.0.FINAL Cluster wide atomic integer and atomic id(uuid+unique cache node id) generation should be supported. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

5
7
0 / 0

[JBoss JIRA] Created: (ISPN-924) Support Atomic arithmetic operations in the API

by Erik Salter (JIRA)

Support Atomic arithmetic operations in the API ----------------------------------------------- Key: ISPN-924 URL: https://issues.jboss.org/browse/ISPN-924 Project: Infinispan Issue Type: Feature Request Reporter: Erik Salter Assignee: Manik Surtani It would be useful if Infinispan supported cluster-wide atomic operations for java.lang.Number types in the API -- similar to the AtomicX API in Java. Right now, to cobble this functionality, we'd need to do something like: - Start a tx - Single-lock a key - Get and increment - Commit - And, of course, handle the cache exceptions =) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

4
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2012