January 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2994) Querying over REST

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2994?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2994: -------------------------------- Component/s: remote query > Querying over REST > ------------------ > > Key: ISPN-2994 > URL: https://issues.jboss.org/browse/ISPN-2994 > Project: Infinispan > Issue Type: Feature Request > Components: remote query > Reporter: Mircea Markus > Assignee: Mircea Markus > > The equivalent of ISPN-484, over the REST interface. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2976) Log4J dependencies in codebase to be cleaned up

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2976?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2976: -------------------------------- Labels: core (was: ) > Log4J dependencies in codebase to be cleaned up > ----------------------------------------------- > > Key: ISPN-2976 > URL: https://issues.jboss.org/browse/ISPN-2976 > Project: Infinispan > Issue Type: Task > Affects Versions: 5.2.5.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Labels: core > > When attempting to move to Log4J 2.0, I've noticed a number of hard deps on log4j classes. > {{SampleConfigFilesCorrectnessTest}} - this class makes use of a custom appender to analyse what a user is being warned of when a config file is parsed. Why are we using Log4J for this? Our own logging interface should be mocked and messages captured directly. > {{RehashStressTest}} and {{NucleotideCache}} - seems like a bug, I presume the author intended to use {{org.infinispan.logging.Log}}. > {{CompressedFileAppender}} and {{ThreadNameFilter}}- can this be written in a way that works with Log4J 1.x as well as 2.x? Or have the SPIs changed that much? -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3395) ISPN000196: Failed to recover cluster state after the current node became the coordinator

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3395?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3395: -------------------------------- Assignee: Dan Berindei (was: Mircea Markus) > ISPN000196: Failed to recover cluster state after the current node became the coordinator > ----------------------------------------------------------------------------------------- > > Key: ISPN-3395 > URL: https://issues.jboss.org/browse/ISPN-3395 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.3.0.Final > Reporter: Mayank Agarwal > Assignee: Dan Berindei > > We are using infinispan 5.3.0.Final in our distributed application. we are testing infinispan in HA scenarios and getting following exception when new node becomes co-ordinator. > ISPN000196: Failed to recover cluster state after the current node became the coordinator > java.lang.NullPointerException: null > at org.infinispan.topology.ClusterTopologyManagerImpl.recoverClusterStatus(ClusterTopologyManagerImpl.java:455) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final] > at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:235) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final] > at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener$1.run(ClusterTopologyManagerImpl.java:647) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final] > at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[na:1.6.0_25] > at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) ~[na:1.6.0_25] > at java.util.concurrent.FutureTask.run(Unknown Source) [na:1.6.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [na:1.6.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [na:1.6.0_25] > at java.lang.Thread.run(Unknown Source) [na:1.6.0_25] > This is happening because cacheTopology is null at ClusterTopologyManagerImpl.java:455 > at 449: code is checking cacheTopology for null that for loop which is updating cacheStatusMap at 457 should be in that check itself. > Fix: > --- a/core/src/main/java/org/infinispan/topology/ClusterTopologyManagerImpl.java > +++ b/core/src/main/java/org/infinispan/topology/ClusterTopologyManagerImpl.java > @@ -448,7 +448,7 @@ public class ClusterTopologyManagerImpl implements ClusterTopologyManager { > // but didn't get a response back yet > if (cacheTopology != null) { > topologyList.add(cacheTopology); > - } > + > > // Add all the members of the topology that have sent responses first > // If we only added the sender, we could end up with a different member order > @@ -457,6 +457,7 @@ public class ClusterTopologyManagerImpl implements ClusterTopologyManager { > cacheStatusMap.get(cacheName).addMember(member); > } > } > + } > -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3455) Cache replication not warranted under load

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3455?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3455: -------------------------------- Component/s: Core > Cache replication not warranted under load > ------------------------------------------ > > Key: ISPN-3455 > URL: https://issues.jboss.org/browse/ISPN-3455 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 5.3.0.Final, 6.0.0.Alpha3 > Environment: JSE 1.6.0_45; Windows 7 > Reporter: Lukasz Szelag > Assignee: Mircea Markus > Attachments: infinispan.zip > > > Problem: > When running a replicated cache and repeatedly calling a cacheable method (using Spring cache abstraction), Infinispan enters an infinite replication loop. This can be confirmed by observing replication counts growing over time, where there are no cache misses. > Expected behavior: > Caches shouldn't be replicated when there is a cache hit. > Test case: > - 3 cluster members; asynchronous replication with a replication queue > - a cacheable method is executed repeatedly using 2 different keys > Notes: > - for some reason, this issue only occurs when using Enum arguments for a cache key; I was not able to replicate this when using int or String types (see com.designamus.infinispan.Main.works()) > - the behavior is not deterministic (random), which points to a race condition > - the problem does not seem to be related to the Spring's default cache key generator; I was able to reproduce the same behavior with a custom cache key generator, which was thread-safe > - the cacheable method is executed only twice (once both keys are stored in the cache); subsequent invocations retrieve stored values from the cache; this can be confirmed by inspecting the log file > - the cache doesn't expire and entries are not evicted > - the memory usage grows over time, eventually causing OOM on a heavily loaded system > - since the issue is random in nature it may take a 3-4 attempts to reproduce it; I was successful in reproducing this behavior numerous times > Steps to reproduce: > 1. Build a test project (mvn clean compile) > 2. Execute /run.sh (this will spawn 3 JVMs) > 3. Start JConsole to monitor 3 cluster members (jconsole localhost:17001 localhost:17002 localhost:17003) > 4. Monitor "replicationCount" attribute under RpcManager for cache "MyCache" for all JVMs (see /replication-counts.png) > 5. Observe that replication counts grow over time > 6. Observe that all caches are of size 2 and there are no cache misses (see /cache-statistics.png) > If the issue cannot be reproduced (replication counts stay at the same level): > 5. Terminate all 3 JVM processes (as a convenience you can execute /stop.sh) > 6. Repeat steps 2 through 5 above > When testing the above scenario using a distributed mode, I observed some other anomalies (i.e. the cacheable method was executed multiple times, as if the value was not there). While this may be related, it deserves a separate JIRA. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3545) Migrate jdbm cache store to the 6.0 cachestore API

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3545?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3545: -------------------------------- Component/s: Loaders and Stores > Migrate jdbm cache store to the 6.0 cachestore API > --------------------------------------------------- > > Key: ISPN-3545 > URL: https://issues.jboss.org/browse/ISPN-3545 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Mircea Markus > Assignee: Mircea Markus > -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3533) Design HotRod protocol version 1.3

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3533?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3533: -------------------------------- Component/s: Remote protocols > Design HotRod protocol version 1.3 > ---------------------------------- > > Key: ISPN-3533 > URL: https://issues.jboss.org/browse/ISPN-3533 > Project: Infinispan > Issue Type: Enhancement > Components: Remote protocols > Reporter: Galder Zamarreño > Assignee: Mircea Markus > > Umbrella JIRA for Hot Rod improvements for version 1.3 -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3460) Refactor the CacheEntry hierarchy

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3460?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3460: -------------------------------- Component/s: Core > Refactor the CacheEntry hierarchy > --------------------------------- > > Key: ISPN-3460 > URL: https://issues.jboss.org/browse/ISPN-3460 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Mircea Markus > Assignee: William Burns > > ATM we keep the metadata information in 3 places: CacheValues, CacheEntries and Metadata. We should move everything in the Metadata and make the CacheValues and the CacheEntries reference it. > Also look at MimeMetadataHelper in REST cache store... -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3460) Refactor the CacheEntry hierarchy

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3460?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3460: -------------------------------- Priority: Minor (was: Major) > Refactor the CacheEntry hierarchy > --------------------------------- > > Key: ISPN-3460 > URL: https://issues.jboss.org/browse/ISPN-3460 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Mircea Markus > Assignee: William Burns > Priority: Minor > > ATM we keep the metadata information in 3 places: CacheValues, CacheEntries and Metadata. We should move everything in the Metadata and make the CacheValues and the CacheEntries reference it. > Also look at MimeMetadataHelper in REST cache store... -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3395) ISPN000196: Failed to recover cluster state after the current node became the coordinator

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3395?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3395: -------------------------------- Component/s: State transfer > ISPN000196: Failed to recover cluster state after the current node became the coordinator > ----------------------------------------------------------------------------------------- > > Key: ISPN-3395 > URL: https://issues.jboss.org/browse/ISPN-3395 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.3.0.Final > Reporter: Mayank Agarwal > Assignee: Mircea Markus > > We are using infinispan 5.3.0.Final in our distributed application. we are testing infinispan in HA scenarios and getting following exception when new node becomes co-ordinator. > ISPN000196: Failed to recover cluster state after the current node became the coordinator > java.lang.NullPointerException: null > at org.infinispan.topology.ClusterTopologyManagerImpl.recoverClusterStatus(ClusterTopologyManagerImpl.java:455) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final] > at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:235) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final] > at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener$1.run(ClusterTopologyManagerImpl.java:647) ~[infinispan-core-5.3.0.1.Final.jar:5.3.0.1.Final] > at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[na:1.6.0_25] > at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) ~[na:1.6.0_25] > at java.util.concurrent.FutureTask.run(Unknown Source) [na:1.6.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [na:1.6.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [na:1.6.0_25] > at java.lang.Thread.run(Unknown Source) [na:1.6.0_25] > This is happening because cacheTopology is null at ClusterTopologyManagerImpl.java:455 > at 449: code is checking cacheTopology for null that for loop which is updating cacheStatusMap at 457 should be in that check itself. > Fix: > --- a/core/src/main/java/org/infinispan/topology/ClusterTopologyManagerImpl.java > +++ b/core/src/main/java/org/infinispan/topology/ClusterTopologyManagerImpl.java > @@ -448,7 +448,7 @@ public class ClusterTopologyManagerImpl implements ClusterTopologyManager { > // but didn't get a response back yet > if (cacheTopology != null) { > topologyList.add(cacheTopology); > - } > + > > // Add all the members of the topology that have sent responses first > // If we only added the sender, we could end up with a different member order > @@ -457,6 +457,7 @@ public class ClusterTopologyManagerImpl implements ClusterTopologyManager { > cacheStatusMap.get(cacheName).addMember(member); > } > } > + } > -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3493) MarshalledValue contains non-serializable members

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3493?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3493: -------------------------------- Component/s: Core > MarshalledValue contains non-serializable members > ------------------------------------------------- > > Key: ISPN-3493 > URL: https://issues.jboss.org/browse/ISPN-3493 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Ray Tsang > Assignee: Mircea Markus > > MarshalledValue implements Serializable. According to JavaDoc: > This class can be marshalled either via its externalizer or via the JVM serialization. > However, MarshalledValueByteStream raw is not serializable. ExpandableMarshalledValueByteStream is also not serializable. > This is causing issues when serializing objects with keys of type MarshalledValue in a cache store. -- 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, 2 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 January 2014