August 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-1328) Upgrade to latest JClouds version

by Galder Zamarreño (JIRA)

Upgrade to latest JClouds version --------------------------------- Key: ISPN-1328 URL: https://issues.jboss.org/browse/ISPN-1328 Project: Infinispan Issue Type: Component Upgrade Components: Loaders and Stores Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.BETA1 This is currently: 1.1.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-1205) Redesign marshallers to be per named cache instance, per thread

by Pete Muir (JIRA)

Redesign marshallers to be per named cache instance, per thread --------------------------------------------------------------- Key: ISPN-1205 URL: https://issues.jboss.org/browse/ISPN-1205 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.0.0.CR6 Reporter: Pete Muir Assignee: Manik Surtani Fix For: 5.1.0.BETA1 Since we have switched to explicit classloaders in Infinispan 5.0, we can now pass the correct classloader to use into JBoss Marshalling, rather than rely on the TCCL. However at the moment marshallers are per thread, not per named cache instance. We will need to change the way marshallers are created to make a marshaller per-thread-per-named-cache-instance. This will also require investigation of the best way of propagating this through the DI system. Dan has previously suggested using the InvocationContext -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

3
11
0 / 0

[JBoss JIRA] Created: (ISPN-279) Avoid instance MarshalledValue accross the code

by Galder Zamarreno (JIRA)

Avoid instance MarshalledValue accross the code ----------------------------------------------- Key: ISPN-279 URL: https://jira.jboss.org/jira/browse/ISPN-279 Project: Infinispan Issue Type: Task Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 Avoid doing things like this in EntryFactoryImpl or EventImpl and instead provide a way for key to be extracted when it somehow needs to be exported to the outside world when lazy serialization is on. if (key instanceof MarshalledValue) { key = ((MarshalledValue) key).get(); } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-1323) TEST_PING doesn't remove the discovery info for a node if findInitialMembers() is called after stop()

by Dan Berindei (JIRA)

TEST_PING doesn't remove the discovery info for a node if findInitialMembers() is called after stop() ----------------------------------------------------------------------------------------------------- Key: ISPN-1323 URL: https://issues.jboss.org/browse/ISPN-1323 Project: Infinispan Issue Type: Bug Components: Test Suite Affects Versions: 5.0.0.FINAL, 5.1.0.ALPHA1 Reporter: Dan Berindei Assignee: Galder Zamarreño Because of https://issues.jboss.org/browse/JGRP-1336, sometimes a node is "resurrected" and TEST_PING.findInitialMembers() is called even after the channel has been stopped. If that happens the node is not removed from the discovery registry and the next node to start from the same test will hang trying to contact the dead node and elect a coordinator. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-1305) Rename the Infinispan annotation

by Kevin Pollet (JIRA)

Rename the Infinispan annotation -------------------------------- Key: ISPN-1305 URL: https://issues.jboss.org/browse/ISPN-1305 Project: Infinispan Issue Type: Task Components: CDI integration Reporter: Kevin Pollet Assignee: Kevin Pollet Priority: Minor Fix For: 5.1.0.BETA1, 5.1.0.FINAL The annotation used to configure a cache is named {{@Infinispan}}. This name doesn't reflect it's purpose. This annotation should be renamed to {{@ConfigureCache}}. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-1316) State transfer coordinator should not ask for state

by Galder Zamarreño (JIRA)

State transfer coordinator should not ask for state --------------------------------------------------- Key: ISPN-1316 URL: https://issues.jboss.org/browse/ISPN-1316 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.0.0.FINAL Reporter: Galder Zamarreño Assignee: Manik Surtani Fix For: 5.1.0.ALPHA1, 5.1.0.FINAL The coordinator of a cluster, which is the first node of the cluster can end up trying to fetch state from other nodes needlessly. For example: 1. A node starts up: {code}15:39:20,443 DEBUG [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) New view accepted: [michal-linhard-12702|0] [michal-linhard-12702]{code} 2. Before state transfer check happens, a new node joins: {code}15:39:20,735 DEBUG [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (pool-5-thread-29) New view accepted: [michal-linhard-12702|1] [michal-linhard-12702, michal-linhard-37465, michal-linhard-61619]{code} 3. Now comes the coordinator which skips itself and sends a state trasnfer req to michal-linhard-37465: {code}15:39:20,902 INFO [org.infinispan.remoting.rpc.RpcManagerImpl] (MSC service thread 1-4) ISPN000074: Trying to fetch state from michal-linhard-37465{code} 4. That's not right, cos 37465 is likely not gonna have anything in memory and this could potentially lead to deadlocks, where 37465 starts and request state from 12702, and in fact, that's what happens: {code}15:39:22,611 INFO [org.infinispan.remoting.rpc.RpcManagerImpl] (MSC service thread 1-4) ISPN000074: Trying to fetch state from michal-linhard-12702{code} 5. In the mean time, as expected, 37465 writes nothing {code}15:39:22,710 DEBUG [org.infinispan.statetransfer.StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,default,michal-linhard-37465) Writing 0 StoredEntries to stream ... 15:39:22,806 TRACE [org.infinispan.transaction.TransactionLog] (STREAMING_STATE_TRANSFER-sender-1,default,michal-linhard-37465) Writing 0 pending prepares to the stream{code} In other words, in the current design, the coordinator should not go around asking for state. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-1315) Reduce number of Logger instances being created

by Sanne Grinovero (JIRA)

Reduce number of Logger instances being created ----------------------------------------------- Key: ISPN-1315 URL: https://issues.jboss.org/browse/ISPN-1315 Project: Infinispan Issue Type: Enhancement Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.1.0.ALPHA1, 5.1.0.FINAL As reported on http://community.jboss.org/thread/170415 it seems that creating a high amount of caches (around ~100) can create 30.000+ Logger instances as AbstractConfigurationBean uses an instance level Logger. This has a significant impact on boot performance in some scenarios, as in the profiler snapshots attached on the forum post. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-1270) Hash cache configurations to make sure they're symmetric in cluster

by Galder Zamarreño (JIRA)

Hash cache configurations to make sure they're symmetric in cluster ------------------------------------------------------------------- Key: ISPN-1270 URL: https://issues.jboss.org/browse/ISPN-1270 Project: Infinispan Issue Type: Enhancement Components: CDI integration Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.0.FINAL On startup, verify that all nodes in the cluster have identical cache configuration, to avoid issues like the one presented in the user forum post. A hash (that's plattform/jvm independent) could be calculated on startup and coordinator could verify that all cache configurations have the same hash all across the cluster. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

3
4
0 / 0

[JBoss JIRA] Created: (ISPN-1106) Rehashing into a running cluster causes shared processing lock contention

by Erik Salter (JIRA)

Rehashing into a running cluster causes shared processing lock contention ------------------------------------------------------------------------- Key: ISPN-1106 URL: https://issues.jboss.org/browse/ISPN-1106 Project: Infinispan Issue Type: Bug Affects Versions: 5.0.0.CR2 Reporter: Erik Salter Assignee: Manik Surtani On our initial test of 5.0.0.CR2, we wanted to test the cluster's rehashing behavior/performance and if all locks were cleaned up. The test was to start two nodes, then add a third node, all the while issuing commands to it. Upon adding a third node, the cluster becomes inoperable. The stack traces is in the following location: http://dl.dropbox.com/u/10929737/5.0.0.CR2/server_node1.log, http://dl.dropbox.com/u/10929737/5.0.0.CR2/server_node2.log, http://dl.dropbox.com/u/10929737/5.0.0.CR2/server_node3.log -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

6
19
0 / 0

[JBoss JIRA] Created: (ISPN-1255) RequestIgnoredException if a node

by Erik Salter (JIRA)

RequestIgnoredException if a node ---------------------------------- Key: ISPN-1255 URL: https://issues.jboss.org/browse/ISPN-1255 Project: Infinispan Issue Type: Bug Reporter: Erik Salter Assignee: Manik Surtani My application exposes its distributed operations via a REST-based infrastructure. To minimize the delta between JBoss starting and the cache starting, I used the new Distributed Executor to "sticky" a task to the data owner of a set of keys (with the same hash code). NOTE: Rehash still causes problems seen in ISPN-1106. (Attached new logs) I see a lot of the following error from the DistributedExecutorService when the new node's cache doesn't start in a timely manner: Reason: java.lang.IllegalStateException: Invalid response {Satriani-52149(PHL)=RequestIgnoredResponse} In addition, I see: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for valid responses! It takes the cache about 2+ minutes at low throughput rate (30 tx/s) to recover. For high throughput rate, the cluster doesn't recover. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

4
15
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2011