October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3572) Do not keep all tasks during CacheStore.process

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3572?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3572: -------------------------------- Fix Version/s: 6.0.0.CR2 6.0.0.Final > Do not keep all tasks during CacheStore.process > ----------------------------------------------- > > Key: ISPN-3572 > URL: https://issues.jboss.org/browse/ISPN-3572 > Project: Infinispan > Issue Type: Quality Risk > Components: Loaders and Stores > Affects Versions: 6.0.0.Beta2 > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Minor > Fix For: 6.0.0.CR2, 6.0.0.Final > > > When using ExecutorCompletionService in CacheStore.process method, results of all tasks are kept in a queue until all tasks are enqueued or even until vast majority is completed. This limits the CacheStore scalability in terms of memory consumption, while the results for each operation are not requested in the end. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2281) Enable inter server endpoint communication in a compatibility mode

by Misha Ali (JIRA)

[ https://issues.jboss.org/browse/ISPN-2281?page=com.atlassian.jira.plugin.... ] Misha Ali commented on ISPN-2281: --------------------------------- Can someone confirm whether the following is documentation about using this feature: http://infinispan.org/docs/6.0.x/infinispan_server_guide/infinispan_serve... If not, I'd appreciate a pointer to the actual notes on how to use this feature instead. > Enable inter server endpoint communication in a compatibility mode > ------------------------------------------------------------------ > > Key: ISPN-2281 > URL: https://issues.jboss.org/browse/ISPN-2281 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: jdg62 > Fix For: 5.3.0.Beta2, 5.3.0.Final > > > Enable a compatibility mode that allows 3 main servers (Hot Rod, Memcached, REST ) and embedded mode (in-VM) to interact with each other. This would require some compatibility mode. > Obviously, this needs to be testable, so possibly adding tests to the 'integration-tests' module. Need to demonstrate storing data in one “client” and accessing from others, modifying in others, and re-accessing in the first. Test should cover each of the 4 “clients” as the initial creator. > When running in this mode, keys to be stored as Strings. In the case of REST and memcached, keys are strings anyway. In the case of Hot Rod, start the server with a flag to determine the encoding used (assuming the HR client uses Strings as well). > For values - polymorphism between a MarshalledValue (in-VM), MemcachedValue, HotRodValue, RESTValue. Lazily convert from one to the other. May need a PortableValue as well, which contains all of the metadata of all of the value types above. > May need to provide and encoding for values as well - to be able to make sense between Hot Rod byte array values and Strings in REST/memcached (base64?). > In-VM may need registration of an Externalizer? -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] Work on ISPN-3633 started by William Burns. > InvalidateL1Command during ST should not cancel writing the entry by ST > ----------------------------------------------------------------------- > > Key: ISPN-3633 > URL: https://issues.jboss.org/browse/ISPN-3633 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Fix For: 6.0.0.Final > > > When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry. > Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3634) Clean up StateTransferDistSharedCacheLoaderFunctionalTest test

by William Burns (JIRA)

William Burns created ISPN-3634: ----------------------------------- Summary: Clean up StateTransferDistSharedCacheLoaderFunctionalTest test Key: ISPN-3634 URL: https://issues.jboss.org/browse/ISPN-3634 Project: Infinispan Issue Type: Task Reporter: William Burns Assignee: William Burns There are still some comments on https://github.com/infinispan/infinispan/pull/2157 that need to be addressed. The test itself passes, this just some housekeeping on the test itself. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2090) Cache get from TransactionCompleted throws IllegalStateException

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2090?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2090: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Cache get from TransactionCompleted throws IllegalStateException > ---------------------------------------------------------------- > > Key: ISPN-2090 > URL: https://issues.jboss.org/browse/ISPN-2090 > Project: Infinispan > Issue Type: Bug > Components: Listeners, Transactions > Reporter: Galder Zamarreño > Assignee: Pedro Ruivo > Priority: Minor > Fix For: 6.0.0.CR2, 6.0.0.Final > > > When implementing @TransactionCompleted in a sync listener, calling cache.get() even when event.isPre=false throws: > {code}IllegalStateException - ActionStatus.COMMITTED is not in a valid state to be invoking cache operations on{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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2090) Cache get from TransactionCompleted throws IllegalStateException

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2090?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2090: -------------------------------- Fix Version/s: 6.0.0.CR2 6.0.0.Final > Cache get from TransactionCompleted throws IllegalStateException > ---------------------------------------------------------------- > > Key: ISPN-2090 > URL: https://issues.jboss.org/browse/ISPN-2090 > Project: Infinispan > Issue Type: Bug > Components: Listeners, Transactions > Reporter: Galder Zamarreño > Assignee: Pedro Ruivo > Priority: Minor > Fix For: 6.0.0.CR2, 6.0.0.Final > > > When implementing @TransactionCompleted in a sync listener, calling cache.get() even when event.isPre=false throws: > {code}IllegalStateException - ActionStatus.COMMITTED is not in a valid state to be invoking cache operations on{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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3404) ClusterCacheLoader NPE when ClusteredGetCommand response value is null

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3404?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3404: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > ClusterCacheLoader NPE when ClusteredGetCommand response value is null > ---------------------------------------------------------------------- > > Key: ISPN-3404 > URL: https://issues.jboss.org/browse/ISPN-3404 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Alpha2 > Reporter: Tomas Sykora > Assignee: Pedro Ruivo > Labels: jdg62GAblocker > Fix For: 6.0.0.CR2, 6.0.0.Final > > Attachments: clusterCacheLoaderNullPointerResponseValueError.txt, server1DR2.log, server2DR2.log > > > We found this issue in DR2 (Alpha2). In Alpha1 this was ok. > Our internal test: > {code:title=Bar.java|borderStyle=solid} > @Test > public void testLazyLoadingWhenStateTransferDisabled() throws Exception { > controller.start(CONTAINER1); > mc = new MemcachedHelper(server1.getMemcachedEndpoint().getInetAddress().getHostName(), server1.getMemcachedEndpoint() > .getPort()); > mc.set("k1", "v1"); > mc.set("k2", "v2"); > assertEquals("v1", mc.get("k1")); > assertEquals("v2", mc.get("k2")); > assertEquals(2, server1.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries()); > controller.start(CONTAINER2); > mc2 = new MemcachedHelper(server2.getMemcachedEndpoint().getInetAddress().getHostName(), server2.getMemcachedEndpoint() > .getPort()); > assertEquals(2, server2.getDefaultCacheManager().getClusterSize()); > //state-transfer = false -> no entries in the newly joined node > assertEquals(0, server2.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries()); > assertEquals("v1", mc2.get("k1")); //lazily load the entries > assertEquals("v2", mc2.get("k2")); > assertEquals(2, server2.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries()); > mc2.set("k3", "v3"); // THIS IS FAILING HERE > assertEquals(3, server2.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries()); > assertEquals(3, server1.getDefaultCacheManager().getCache(CACHE_NAME).getNumberOfEntries()); > controller.kill(CONTAINER2); > controller.kill(CONTAINER1); > } > {code} > *mc2.set("k3", "v3"); = put into memcached cache, is throwing an exception: see in attachment.* > You can see MemcachedHelper class here: https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests.... > I also include trace logs for both memcached jdg servers if they can be useful. > --------------- > I was able to replicate the same error in Infinispan test suite for Rest endpoint. It was enough to start 2 REST nodes and issue 1 put resulting into the same error. > {code:title=Bar.java|borderStyle=solid} > ConfigurationBuilder cfgBuilder = AbstractCacheTest.getDefaultClusteredCacheConfig(CacheMode.REPL_SYNC, false); > cfgBuilder.clustering().hash().numOwners(1); > cfgBuilder.clustering().stateTransfer().fetchInMemoryState(false); > cfgBuilder.clustering().stateTransfer().timeout(20000); > cfgBuilder.loaders().addClusterCacheLoader().remoteCallTimeout(60000); > RestServerConfigurationBuilder restCfgBuilder = new RestServerConfigurationBuilder(); > addServer("1", 8890, TestCacheManagerFactory.createClusteredCacheManager(cfgBuilder), restCfgBuilder.build()); > addServer("2", 8891, TestCacheManagerFactory.createClusteredCacheManager(cfgBuilder), restCfgBuilder.build()); > startServers(); > ...... > PutMethod put = new PutMethod(PATH1 + "key1"); > put.setRequestEntity(new StringRequestEntity("value1", "application/text", null)); > call(put); > assertEquals(put.getStatusCode(), HttpServletResponse.SC_OK); > put.releaseConnection(); > {code} > This scenario is different from aforementioned JDG internal test suite one but I expect this should be ok and should be performed without any problems. > -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3552) HotRod Rolling Upgrades NPE when disabling cache store on target node

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3552?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3552: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > HotRod Rolling Upgrades NPE when disabling cache store on target node > --------------------------------------------------------------------- > > Key: ISPN-3552 > URL: https://issues.jboss.org/browse/ISPN-3552 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Beta1 > Reporter: Tomas Sykora > Assignee: Pedro Ruivo > Priority: Critical > Labels: jdg62GAblocker > Fix For: 6.0.0.CR2 > > Attachments: standalone-source-node-rollups52-dist.xml, standalone-target-node-rollups-dist.xml > > > After Tristan's fix for https://issues.jboss.org/browse/ISPN-3183 we can move successfully through recordKnownGlobalKeyset and synchronizeData operations. > However, when we want to issue disconnectSource operation on target node, it is failing with given error: > javax.management.MBeanException > at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:273) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791) > at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:527) > at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:263) > at org.jboss.remotingjmx.protocol.v1.ServerProxy$InvokeHandler.handle(ServerProxy.java:1058) > at org.jboss.remotingjmx.protocol.v1.ServerProxy$MessageReciever$1.run(ServerProxy.java:225) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > Caused by: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:271) > ... 9 more > Caused by: java.lang.NullPointerException > at org.infinispan.persistence.manager.PersistenceManagerImpl.disableStore(PersistenceManagerImpl.java:253) > at org.infinispan.persistence.remote.upgrade.HotRodTargetMigrator.disconnectSource(HotRodTargetMigrator.java:101) > at org.infinispan.upgrade.RollingUpgradeManager.disconnectSource(RollingUpgradeManager.java:71) > ... 14 more > Short input from Tristan: "problem is that after removing the store, it determines there are no more stores left so it tries to remove the loader/writer interceptors which for some reason are missing" > -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3620) Move the programmatic search mappings required by remote query out of query module ModuleLifecycle

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3620?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3620: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Move the programmatic search mappings required by remote query out of query module ModuleLifecycle > -------------------------------------------------------------------------------------------------- > > Key: ISPN-3620 > URL: https://issues.jboss.org/browse/ISPN-3620 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Affects Versions: 6.0.0.CR1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 6.0.0.CR2 > > > Currently this was worked around by reflection hacks but the proper way to solve this is to use the Provider mechanism. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3633: -------------------------------- Assignee: William Burns (was: Mircea Markus) > InvalidateL1Command during ST should not cancel writing the entry by ST > ----------------------------------------------------------------------- > > Key: ISPN-3633 > URL: https://issues.jboss.org/browse/ISPN-3633 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > > When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry. > Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once. -- 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, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2013