[JBoss JIRA] (ISPN-2235) allow referencing jgroups config file from spring
by Radim Kolář (JIRA)
Radim Kolář created ISPN-2235:
---------------------------------
Summary: allow referencing jgroups config file from spring
Key: ISPN-2235
URL: https://issues.jboss.org/browse/ISPN-2235
Project: Infinispan
Issue Type: Enhancement
Components: Spring integration
Affects Versions: 5.1.6.FINAL
Environment: Spring 3.1
Reporter: Radim Kolář
Assignee: Mircea Markus
For more easy configuration add to SpringEmbeddedCacheManagerFactoryBean possibility to directly reference to jgroups transport configuration.
method
setTransportConfigurationFile -> point to jgroups.xml
--
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, 11 months
[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, 11 months
[JBoss JIRA] (ISPN-2367) ReadCommitted does not work in distributed mode
by Mircea Markus (JIRA)
Mircea Markus created ISPN-2367:
-----------------------------------
Summary: ReadCommitted does not work in distributed mode
Key: ISPN-2367
URL: https://issues.jboss.org/browse/ISPN-2367
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 5.1.7.Final
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 5.2.0.Final
ReadCommitted isolation level doesn't work as expected in distributed mode:
- tx1@Node1 reads (k1,v1) which is owned by Node2. At this point it keeps a cached copy of the entry locally
- tx2@Node3 writes (k1,v2) and commits
- tx1@Node1 reads k1 again and it gets the value "v1" - wrong!
--
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, 11 months
[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, 11 months
[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, 11 months
[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, 11 months