[JBoss JIRA] (ISPN-3407) Entry passivation doesn't work according to eviction strategy
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3407?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3407 started by Galder Zamarreño.
> Entry passivation doesn't work according to eviction strategy
> -------------------------------------------------------------
>
> Key: ISPN-3407
> URL: https://issues.jboss.org/browse/ISPN-3407
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.3.0.Final
> Reporter: Vitalii Chepeliuk
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> {code:title=Test.java|borderStyle=solid}
> GlobalConfiguration globalConf = new GlobalConfigurationBuilder().nonClusteredDefault().build();
> ConfigurationBuilder builder = new ConfigurationBuilder();
> builder.clustering().cacheMode(CacheMode.LOCAL)
> .loaders().passivation(true).preload(false).shared(false)
> .addLoader(JdbcStringBasedCacheStoreConfigurationBuilder.class).fetchPersistentState(false).purgeOnStartup(false)
> .table()
> .databaseType(DatabaseType.MYSQL)
> .dropOnExit(false)
> .createOnStart(true)
> .tableNamePrefix("ISPN6Alpha2_STRING")
> .idColumnName("ID").idColumnType("VARCHAR(255)")
> .dataColumnName("DATA").dataColumnType("VARBINARY(1000)")
> .timestampColumnName("TIMESTAMP").timestampColumnType("BIGINT")
> .connectionPool()
> .connectionUrl()
> .username("username")
> .password("password")
> .driverClass("com.mysql.jdbc.Driver")
> .eviction().strategy(EvictionStrategy.LRU).maxEntries(2);
> Configuration localConf = builder.build();
> DefaultCacheManager defCacheManager = new DefaultCacheManager(globalConf, localConf, true);
> Cache<String, String> cache = defCacheManager.getCache();
> cache.put("k1", "v1");
> cache.put("k2", "v2");
> //not yet in store (eviction.max-entries=2, LRU)
> cache.put("k3", "v3");
> assertEquals("v3", cache.get("k3"));
> //now k1 evicted and stored in store
> assertEquals(2, cache.size()); <<< only 2 entries should remain in cache, k1 should be passivated and removed. But doesn't work!
> {code}
--
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, 5 months
[JBoss JIRA] (ISPN-2999) getCacheEntry not working when distribution gets go remote
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2999?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2999:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2206
> getCacheEntry not working when distribution gets go remote
> ----------------------------------------------------------
>
> Key: ISPN-2999
> URL: https://issues.jboss.org/browse/ISPN-2999
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.5.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> Assuming the cache contains byte[], you get this exception when calling getCacheEntry(K) for a key not available locally:
> {code}org.infinispan.server.hotrod.HotRodException: java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry
> at org.infinispan.server.hotrod.HotRodDecoder.createServerException(HotRodDecoder.scala:216)
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:79)
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:49)
> at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500)
> at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435)
> at org.infinispan.server.core.AbstractProtocolDecoder.messageReceived(AbstractProtocolDecoder.scala:393)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107)
> at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:313)
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88)
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:680)
> Caused by: java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry
> at org.infinispan.CacheImpl.getCacheEntry(CacheImpl.java:299)
> at org.infinispan.CacheImpl.getCacheEntry(CacheImpl.java:304)
> at org.infinispan.server.core.AbstractProtocolDecoder.get(AbstractProtocolDecoder.scala:287)
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeKey(AbstractProtocolDecoder.scala:117)
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:73)
> ... 14 more{code}
--
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, 5 months
[JBoss JIRA] (ISPN-3531) LifecycleManager of query module keeps references to per cache manager resources (jmx related)
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3531?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-3531:
-------------------------------------
Please note that the fix requires changing the object name of MassIndexer to obey the naming scheme, which then might impact RHQ and some more tests.
> LifecycleManager of query module keeps references to per cache manager resources (jmx related)
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-3531
> URL: https://issues.jboss.org/browse/ISPN-3531
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 6.0.0.Alpha4
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> The resources in question are gathered when a cache manager is started and are used again when it is stopped. This does not work well if there are multiple cache managers that have different jmx domains.
> Cache stop event also does not seem to be processed correctly.
--
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, 5 months
[JBoss JIRA] (ISPN-3531) LifecycleManager of query module keeps references to per cache manager resources (jmx related)
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3531?page=com.atlassian.jira.plugin.... ]
Adrian Nistor edited comment on ISPN-3531 at 11/11/13 5:53 AM:
---------------------------------------------------------------
I've revisited this issue and found that my initial analysis was completely wrong, the title and description are completely inaccurate, but there still is an issue here with the unregistering of MBeans during cache stop; a bit different one though.
First of all, the problem I noticed initially was the MassIndexer MBean disappearing from the MBean server if there were two cache managers and one of them was shut down at some point. My problem was that the MassIndexer of ALL created caches was unregistered, not just of the ones from the cache manager being shut down. In my case the two (differently named) cache managers were sharing the same jmx domain (contrary to what I said in description - I was confused).
It turns out the problem is the object name of the MassIndexer (and possibly some other components??) does not contain the cache manager name as an attribute. The usual naming scheme for cache components is: {{jmxDomain + ":type=" + aType + ",manager=" + ObjectName.quote(cacheManagerName) + ",name=" + ObjectName.quote(cacheName) + ",component=" + aComponentName}}, but for the MassIndexer the cache manager name part is missing, so the wildcard MBean query used for unregistering (in org.infinispan.query.impl.LifecycleManager.cacheStopping()) matches a bit more instances than intended.
So, should we close this as invalid and create a new issue for the newly described case?
was (Author: anistor):
I've revisited this issue and found that my initial analysis was completely wrong, the title and description are completely inaccurate, but there still is an issue here with the unregistering of MBeans during cache stop; a bit different one though.
First of all, the problem I noticed initially was the MassIndexer MBean disappearing from the MBean server if there were two cache managers and one of them was shut down at some point. My problem was that the MassIndexer of ALL created caches was unregistered, not just of the ones from the cache manager being shut down. In my case the two (differently named) cache managers were sharing the same jmx domain (contrary to what I said in description - I was confused).
It turns out the problem is the object name of the MassIndexer (and possibly some other components??) does not contain the cache manager name as an attribute. The usual naming scheme for cache components is: ```jmxDomain + ":type=" + aType + ",manager=" + ObjectName.quote(cacheManagerName) + ",name=" + ObjectName.quote(cacheName) + ",component=" + aComponentName```, but for the MassIndexer the cache manager name part is missing, so the wildcard MBean query used for unregistering (in org.infinispan.query.impl.LifecycleManager.cacheStopping()) matches a bit more instances than intended.
So, should we close this as invalid and create a new issue for the newly described case?
> LifecycleManager of query module keeps references to per cache manager resources (jmx related)
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-3531
> URL: https://issues.jboss.org/browse/ISPN-3531
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 6.0.0.Alpha4
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> The resources in question are gathered when a cache manager is started and are used again when it is stopped. This does not work well if there are multiple cache managers that have different jmx domains.
> Cache stop event also does not seem to be processed correctly.
--
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, 5 months
[JBoss JIRA] (ISPN-3531) LifecycleManager of query module keeps references to per cache manager resources (jmx related)
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3531?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-3531:
-------------------------------------
I've revisited this issue and found that my initial analysis was completely wrong, the title and description are completely inaccurate, but there still is an issue here with the unregistering of MBeans during cache stop; a bit different one though.
First of all, the problem I noticed initially was the MassIndexer MBean disappearing from the MBean server if there were two cache managers and one of them was shut down at some point. My problem was that the MassIndexer of ALL created caches was unregistered, not just of the ones from the cache manager being shut down. In my case the two (differently named) cache managers were sharing the same jmx domain (contrary to what I said in description - I was confused).
It turns out the problem is the object name of the MassIndexer (and possibly some other components??) does not contain the cache manager name as an attribute. The usual naming scheme for cache components is: ```jmxDomain + ":type=" + aType + ",manager=" + ObjectName.quote(cacheManagerName) + ",name=" + ObjectName.quote(cacheName) + ",component=" + aComponentName```, but for the MassIndexer the cache manager name part is missing, so the wildcard MBean query used for unregistering (in org.infinispan.query.impl.LifecycleManager.cacheStopping()) matches a bit more instances than intended.
So, should we close this as invalid and create a new issue for the newly described case?
> LifecycleManager of query module keeps references to per cache manager resources (jmx related)
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-3531
> URL: https://issues.jboss.org/browse/ISPN-3531
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 6.0.0.Alpha4
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> The resources in question are gathered when a cache manager is started and are used again when it is stopped. This does not work well if there are multiple cache managers that have different jmx domains.
> Cache stop event also does not seem to be processed correctly.
--
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, 5 months
[JBoss JIRA] (ISPN-3695) Atomic Object Factory
by Pierre Sutra (JIRA)
Pierre Sutra created ISPN-3695:
----------------------------------
Summary: Atomic Object Factory
Key: ISPN-3695
URL: https://issues.jboss.org/browse/ISPN-3695
Project: Infinispan
Issue Type: Feature Request
Components: Core API
Affects Versions: 6.0.0.Final
Reporter: Pierre Sutra
Assignee: Mircea Markus
Priority: Optional
This feature implements a factory of atomic objects. The factory is universal in the sense that it can instanciate an object of any class. Below, we illusrate the usage of such a factory.
AtomicObjectFactory factory = new AtomicObjectFactory(c1); // c1 is both synchronous and transactional
Set set = (Set) factory.getOrCreateInstanceOf(HashSet.class, "k"); // k is the key to store set inside c1
set.add("smthing"); // some call examples
System.out.println(set.toString())
set.addAll(set);
factory.disposeInstanceOf(HashSet.class, "set", true); // to store in a persistent way the object
The implementation requires that all the arguments of the methods of the object are Serializable, as well as the object itself. The factory is built on top of the transactional facility of Infinispan. When an object is created, it stores both a local copy and a proxy registered as a cache listener. Then, it serializes every call in a transaction consisting of a single put operation. When the call is de-serialized its applied to the local copy and, in case the calling process was local, the return value is returned (this mechanism is implemented via a future object).
--
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, 5 months
[JBoss JIRA] (ISPN-3693) ActivationInterceptor on get always deletes store contents
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3693?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3693:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2203
> ActivationInterceptor on get always deletes store contents
> ----------------------------------------------------------
>
> Key: ISPN-3693
> URL: https://issues.jboss.org/browse/ISPN-3693
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: William Burns
> Assignee: William Burns
> Priority: Blocker
> Fix For: 6.0.0.CR2
>
>
> The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
> Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
> The following describes this scenario
> {code}
> t1 -> calls get retrieves value from context (dc)
> t2 -> calls evict retrieves value from context (dc)
> t2 -> passivates entry (writes entry to loader)
> t1 -> activates entry (removes entry from loader)
> t2 -> removes entry from dc
> {code}
> Note this doesn't affect size based eviction.
--
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, 5 months