[JBoss JIRA] (ISPN-3407) Entry passivation doesn't work according to eviction strategy
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3407?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3407:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> made a comment on [bug 996876|https://bugzilla.redhat.com/show_bug.cgi?id=996876]
We should fix the test then. Closing this BZ.
> 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
>
> {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-3407) Entry passivation doesn't work according to eviction strategy
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3407?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3407:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 996876|https://bugzilla.redhat.com/show_bug.cgi?id=996876] from ASSIGNED to CLOSED
> 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
>
> {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-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.... ]
Galder Zamarreño commented on ISPN-3407:
----------------------------------------
Ever since ISPN-761 was fixed, size() takes into account entries that are stored in the cache store as well. So, this is working as expected.
> 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-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.... ]
Galder Zamarreño resolved ISPN-3407.
------------------------------------
Fix Version/s: (was: 6.0.0.Final)
Resolution: Rejected
> 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
>
> {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-3698) Failure during concurrent restart of cache/manager
by Paul Ferraro (JIRA)
Paul Ferraro created ISPN-3698:
----------------------------------
Summary: Failure during concurrent restart of cache/manager
Key: ISPN-3698
URL: https://issues.jboss.org/browse/ISPN-3698
Project: Infinispan
Issue Type: Bug
Components: Core API
Affects Versions: 6.0.0.CR1, 5.2.7.Final
Reporter: Paul Ferraro
Assignee: Mircea Markus
Priority: Critical
These failures prevent the cache from starting successfully, and consequently the redeploy to fail. There are 3 stack traces of note in the logs:
{noformat}
15:05:32,044 ERROR [org.jgroups.blocks.RequestCorrelator] (OOB-20,shared=udp) failed unmarshalling buffer into return value: java.lang.NullPointerException
at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:150)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:355) [jboss-marshalling-river-1.4.2.Final.jar:1.4.2.Final]
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213) [jboss-marshalling-river-1.4.2.Final.jar:1.4.2.Final]
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:45) [jboss-marshalling-1.4.2.Final.jar:1.4.2.Final]
at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:140)
at org.infinispan.marshall.core.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:96)
at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:80)
at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:28)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:665)
at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
at org.jgroups.JChannel.up(JChannel.java:708)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1015)
at org.jgroups.protocols.RSVP.up(RSVP.java:187)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:370)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1010)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:698)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:381)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:184)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
at org.jgroups.protocols.MERGE3.up(MERGE3.java:303)
at org.jgroups.protocols.Discovery.up(Discovery.java:379)
at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2534)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1389)
at org.jgroups.protocols.TP$MyHandler.run(TP.java:1540)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
15:43:48,482 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 58) MSC000001: Failed to start service jboss.infinispan.ejb.remote-connector-client-mappings: org.jboss.msc.service.StartException in service jboss.infinispan.ejb.remote-connector-client-mappings: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.start() throws java.lang.Exception on object of type StateTransferManagerImpl
at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.start() throws java.lang.Exception on object of type StateTransferManagerImpl
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:871)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
at org.infinispan.CacheImpl.start(CacheImpl.java:666)
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:551)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:514)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:396)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:410)
at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
... 4 more
Caused by: org.infinispan.commons.CacheException: java.lang.NullPointerException
at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:557)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:176)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:505)
at org.infinispan.topology.LocalTopologyManagerImpl.executeOnCoordinator(LocalTopologyManagerImpl.java:277)
at org.infinispan.topology.LocalTopologyManagerImpl.join(LocalTopologyManagerImpl.java:91)
at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
... 18 more
Caused by: java.lang.NullPointerException
at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:150)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:355)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:45) [jboss-marshalling-1.4.2.Final.jar:1.4.2.Final]
at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:140)
at org.infinispan.marshall.core.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:96)
at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:80)
at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:28)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:665)
at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
at org.jgroups.JChannel.up(JChannel.java:708)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1015)
at org.jgroups.protocols.RSVP.up(RSVP.java:187)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:381)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:370)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1010)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:698)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:381)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:184)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
at org.jgroups.protocols.MERGE3.up(MERGE3.java:303)
at org.jgroups.protocols.Discovery.up(Discovery.java:379)
at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2534)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1389)
at org.jgroups.protocols.TP$MyHandler.run(TP.java:1540)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)15:43:48,502 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 59) MSC000001: Failed to start service jboss.infinispan.ejb.repl: org.jboss.msc.service.StartException in service jboss.infinispan.ejb.repl: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.start() throws java.lang.Exception on object of type StateTransferManagerImpl
at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.start() throws java.lang.Exception on object of type StateTransferManagerImpl
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:871)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
at org.infinispan.CacheImpl.start(CacheImpl.java:666)
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:551)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:514)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:396)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:410)
at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:103)
at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:94)
at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
... 4 more
Caused by: org.infinispan.commons.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)
at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:557)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:176)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:505)
at org.infinispan.topology.LocalTopologyManagerImpl.executeOnCoordinator(LocalTopologyManagerImpl.java:277)
at org.infinispan.topology.LocalTopologyManagerImpl.join(LocalTopologyManagerImpl.java:91)
at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
... 18 more
Caused by: java.lang.RuntimeException: Failure to marshal argument(s)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:333)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:352)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167)
... 27 more
Caused by: java.lang.NullPointerException
at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.getObjectWriter(JBossMarshaller.java:145)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:142)
at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62) [jboss-marshalling-1.4.2.Final.jar:1.4.2.Final]
at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:115) [jboss-marshalling-1.4.2.Final.jar:1.4.2.Final]
at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectToObjectStream(AbstractJBossMarshaller.java:78)
at org.infinispan.marshall.core.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:72)
at org.infinispan.commons.marshall.AbstractMarshaller.objectToBuffer(AbstractMarshaller.java:41)
at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectToBuffer(AbstractDelegatingMarshaller.java:85)
at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectToBuffer(MarshallerAdapter.java:23)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:331)
... 29 more
Caused by: an exception which occurred:
in object org.infinispan.topology.CacheTopologyControlCommand@f80b63c
[rt.jar:1.7.0_25]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
{noformat}
--
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-3697) Improved lifecycle control of JGroupsChannelLookup
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-3697?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated ISPN-3697:
-------------------------------
Description:
Currently, a JGroupsChannelLookup can indicate whether the JGroupsTransport should connect the provided channel and disconnect/close the provided channel.
In the case of Wildfly, we'd like to distinguish between disconnect and close. We have a service that provided the channel, but we allow the JGroupsTransport to manage the lifecycle. This leads to conditions where infinispan's cache manager can restart, but the jgroups channel service does not, e.g.
https://issues.jboss.org/browse/WFLY-2458
To fix this, I need to introduce hacks into the channel returned by the channel service, such that Channel.close() is a no-op, and introduce a separate method invisible to Infinispan to perform the actual close().
So what I propose is the following:
boolean shouldConnect(); // Notice that I renamed this, because there is no such distinction between "start" and "connect".
boolean shouldDisconnect();
boolean shouldClose();
was:
Currently, a JGroupsChannelLookup can indicate whether the JGroupsTransport should connect the provided channel and disconnect/close the provided channel.
In the case of Wildfly, we'd like to distinguish between disconnect and close. We have a service that provided the channel, but we allow the JGroupsTransport to manage the lifecycle. This leads to conditions where infinispan's cache manager can restart, but the jgroups channel service does not. This leads to conditions like:
https://issues.jboss.org/browse/WFLY-2458
To fix this, I need to introduce hacks into the channel returned by the channel service, such that Channel.close() is a no-op, and introduce a separate method invisible to Infinispan to perform the actual close().
So what I propose is the following:
boolean shouldConnect(); // Notice that I renamed this, because there is no such distinction between "start" and "connect".
boolean shouldDisconnect();
boolean shouldClose();
> Improved lifecycle control of JGroupsChannelLookup
> --------------------------------------------------
>
> Key: ISPN-3697
> URL: https://issues.jboss.org/browse/ISPN-3697
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API
> Affects Versions: 6.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Mircea Markus
> Fix For: 6.0.0.Final
>
>
> Currently, a JGroupsChannelLookup can indicate whether the JGroupsTransport should connect the provided channel and disconnect/close the provided channel.
> In the case of Wildfly, we'd like to distinguish between disconnect and close. We have a service that provided the channel, but we allow the JGroupsTransport to manage the lifecycle. This leads to conditions where infinispan's cache manager can restart, but the jgroups channel service does not, e.g.
> https://issues.jboss.org/browse/WFLY-2458
> To fix this, I need to introduce hacks into the channel returned by the channel service, such that Channel.close() is a no-op, and introduce a separate method invisible to Infinispan to perform the actual close().
> So what I propose is the following:
> boolean shouldConnect(); // Notice that I renamed this, because there is no such distinction between "start" and "connect".
> boolean shouldDisconnect();
> boolean shouldClose();
--
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-3697) Improved lifecycle control of JGroupsChannelLookup
by Paul Ferraro (JIRA)
Paul Ferraro created ISPN-3697:
----------------------------------
Summary: Improved lifecycle control of JGroupsChannelLookup
Key: ISPN-3697
URL: https://issues.jboss.org/browse/ISPN-3697
Project: Infinispan
Issue Type: Feature Request
Components: Core API
Affects Versions: 6.0.0.CR1
Reporter: Paul Ferraro
Assignee: Mircea Markus
Fix For: 6.0.0.Final
Currently, a JGroupsChannelLookup can indicate whether the JGroupsTransport should connect the provided channel and disconnect/close the provided channel.
In the case of Wildfly, we'd like to distinguish between disconnect and close. We have a service that provided the channel, but we allow the JGroupsTransport to manage the lifecycle. This leads to conditions where infinispan's cache manager can restart, but the jgroups channel service does not. This leads to conditions like:
https://issues.jboss.org/browse/WFLY-2458
To fix this, I need to introduce hacks into the channel returned by the channel service, such that Channel.close() is a no-op, and introduce a separate method invisible to Infinispan to perform the actual close().
So what I propose is the following:
boolean shouldConnect(); // Notice that I renamed this, because there is no such distinction between "start" and "connect".
boolean shouldDisconnect();
boolean shouldClose();
--
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-3048) Eviction needs to be transactional
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3048?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-3048:
-----------------------------------
hi [~pferraro]
I'm not convinced that the eviction needs to be transactional. It happens under the segment lock in the hash map and it is saved to disk before it is removed from the [in memory] map. Also, if a retrieve operation happens at the same time and the entry is not longer in memory, it is going to look at the cache loader. So, looking at the code, I don't see where the retrieve operation can return null but I'm going to try to do some tests around it.
Anyway, do we have any some kind of discussion to turn the eviction transactional? personally, I don't like the idea...
finally, are you sure that you are not hitting this: https://issues.jboss.org/browse/ISPN-3694
Does it happen with passivation disabled?
thanks!
> Eviction needs to be transactional
> ----------------------------------
>
> Key: ISPN-3048
> URL: https://issues.jboss.org/browse/ISPN-3048
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.3.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> Currently, Infinispan eviction is non-transactional. This makes Infinispan's eviction manager virtually unusable, since non-transactional eviction can cause phantom reads and data loss because it violates the isolation of concurrent transactions. This is especially problematic when using a passivation-enabled cache store. In this case, a cache eviction/passivation can cause a concurrently executed cache retrieval to return null - even though the act of passivation does not change the data - it only changes where it is stored.
> We work around this in the AS by performing eviction manually, using pessimistic locking in combination with eager lock acquisition prior to eviction. This is unfortunate, since it prevents me from leveraging Infinispan's build-in eviction strategies.
--
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-3048) Eviction needs to be transactional
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-3048?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on ISPN-3048:
------------------------------------
It is also essential that the eviction listeners be notified within the context of the transaction
> Eviction needs to be transactional
> ----------------------------------
>
> Key: ISPN-3048
> URL: https://issues.jboss.org/browse/ISPN-3048
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.3.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> Currently, Infinispan eviction is non-transactional. This makes Infinispan's eviction manager virtually unusable, since non-transactional eviction can cause phantom reads and data loss because it violates the isolation of concurrent transactions. This is especially problematic when using a passivation-enabled cache store. In this case, a cache eviction/passivation can cause a concurrently executed cache retrieval to return null - even though the act of passivation does not change the data - it only changes where it is stored.
> We work around this in the AS by performing eviction manually, using pessimistic locking in combination with eager lock acquisition prior to eviction. This is unfortunate, since it prevents me from leveraging Infinispan's build-in eviction strategies.
--
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-3048) Eviction needs to be transactional
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3048?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3048 started by Pedro Ruivo.
> Eviction needs to be transactional
> ----------------------------------
>
> Key: ISPN-3048
> URL: https://issues.jboss.org/browse/ISPN-3048
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.3.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.0.0.Final
>
>
> Currently, Infinispan eviction is non-transactional. This makes Infinispan's eviction manager virtually unusable, since non-transactional eviction can cause phantom reads and data loss because it violates the isolation of concurrent transactions. This is especially problematic when using a passivation-enabled cache store. In this case, a cache eviction/passivation can cause a concurrently executed cache retrieval to return null - even though the act of passivation does not change the data - it only changes where it is stored.
> We work around this in the AS by performing eviction manually, using pessimistic locking in combination with eager lock acquisition prior to eviction. This is unfortunate, since it prevents me from leveraging Infinispan's build-in eviction strategies.
--
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