October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3404) ClusterCacheLoader - 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: -------------------------------- Fix Version/s: 6.0.0.Final > ClusterCacheLoader - 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: William Burns > 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-3404) ClusterCacheLoader - 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: -------------------------------- Assignee: Pedro Ruivo (was: William Burns) > ClusterCacheLoader - 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-3616) add user documentation for the new cache store API

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3616: ----------------------------------- Summary: add user documentation for the new cache store API Key: ISPN-3616 URL: https://issues.jboss.org/browse/ISPN-3616 Project: Infinispan Issue Type: Task 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3616) add user documentation for the new cache store API

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3616?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3616: -------------------------------- Fix Version/s: 6.0.0.Final > add user documentation for the new cache store API > -------------------------------------------------- > > Key: ISPN-3616 > URL: https://issues.jboss.org/browse/ISPN-3616 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 6.0.0.Final > > -- 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-3454) Hot Rod client doesn't retry operation on RemoteException

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3454?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3454: -------------------------------- Priority: Critical (was: Major) > Hot Rod client doesn't retry operation on RemoteException > --------------------------------------------------------- > > Key: ISPN-3454 > URL: https://issues.jboss.org/browse/ISPN-3454 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Alpha3 > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Priority: Critical > Labels: jdg62GAblocker > Fix For: 6.0.0.CR2, 6.0.0.Final > > > This is a client-side problem. > In a resilience test with 4 nodes where 1 is killed, I'm getting a lot of these: > {code} > 08:30:55,198 ERROR [org.jboss.smartfrog.jdg.loaddriver.DriverThread] (DriverThread-369) Error doing: PUT key399869 to node node04, took 493 ms > org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[821188] returned server error (status=0x85): org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node01/default, see cause for remote stack trace > at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143) > at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50) > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30) > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:209) > at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) > at org.jboss.qa.jdg.adapter.Infinispan60Adapter$HotRodRemoteCacheAdapter.put(Infinispan60Adapter.java:269) > at org.jboss.smartfrog.jdg.loaddriver.DriverThreadImpl.makeRequest(DriverThreadImpl.java:265) > at org.jboss.smartfrog.jdg.loaddriver.DriverThreadImpl.run(DriverThreadImpl.java:378) > {code} > Isn't this a recoverable problem that shouldn't be left to user to handle ? > source: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/RESILIENCE... -- 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-3270) Hotrod clients removeWithVersion doesn't work with replicated cache

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3270?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3270: -------------------------------- Priority: Critical (was: Major) > Hotrod clients removeWithVersion doesn't work with replicated cache > ------------------------------------------------------------------- > > Key: ISPN-3270 > URL: https://issues.jboss.org/browse/ISPN-3270 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 6.0.0.Beta1 > Reporter: Jakub Markos > Assignee: Galder Zamarreño > Priority: Critical > Labels: jdg62GAblocker > Fix For: 6.0.0.Final > > Attachments: server-trace-logs.zip > > > I have a cluster of 2 latest infinispan servers (6.0.0-SNAPSHOT) with the following container configuration: > {code:xml}<cache-container name="default" default-cache="default" listener-executor="infinispan-listener"> > <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/> > <replicated-cache name="default" start="EAGER" mode="SYNC" batching="false" remote-timeout="60000"> > <transaction mode="NONE"/> > <state-transfer enabled="true" timeout="60000"/> > </replicated-cache> > </cache-container> > {code} > Running this code: > {code} remoteCache = remoteCacheManager.getCache(); > remoteCache.clear(); > assertFalse(remoteCache.removeWithVersion("aKey", 12321212l)); > remoteCache.put("aKey", "aValue"); > VersionedValue valueBinary = remoteCache.getVersioned("aKey"); > System.out.println("value = " + valueBinary.getValue()); > System.out.println("version = " + valueBinary.getVersion()); > System.out.println(remoteCache.removeWithVersion("aKey",valueBinary.getVersion())); > valueBinary = remoteCache.getVersioned("aKey"); > System.out.println("value = " + valueBinary.getValue()); > System.out.println("version = " + valueBinary.getVersion()); > {code} > results most of the time in (and the other times the removeWithVersion returns false) > {quote} > value = aValue > version = 281483566645249 > true > value = aValue > version = 281483566645249 > {quote} > The command works with distributed/local cache. -- 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-3615) Add user documentation for the remote query modules

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3615: ----------------------------------- Summary: Add user documentation for the remote query modules Key: ISPN-3615 URL: https://issues.jboss.org/browse/ISPN-3615 Project: Infinispan Issue Type: Task Reporter: Mircea Markus Assignee: Adrian Nistor -- 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-3615) Add user documentation for the remote query modules

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3615?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3615: -------------------------------- Fix Version/s: 6.0.0.Final > Add user documentation for the remote query modules > --------------------------------------------------- > > Key: ISPN-3615 > URL: https://issues.jboss.org/browse/ISPN-3615 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Adrian Nistor > Fix For: 6.0.0.Final > > -- 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-3614) Add remote query quick start

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3614: ----------------------------------- Summary: Add remote query quick start Key: ISPN-3614 URL: https://issues.jboss.org/browse/ISPN-3614 Project: Infinispan Issue Type: Task Reporter: Mircea Markus Assignee: Adrian Nistor Fix For: 6.0.0.CR2 Should describe how the users: - download the servers - configure it (indexing ...) - with sample domain model, how to write the marshallers, define the indexes using the RHQ plugin - some code that connects to the server, adds and queries the data (mvn module?) -- 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-3599) CommitCommand with replayed PrepareCommand executes rollback and then commit

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3599?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3599: -------------------------------- Fix Version/s: 6.0.0.CR2 > CommitCommand with replayed PrepareCommand executes rollback and then commit > ---------------------------------------------------------------------------- > > Key: ISPN-3599 > URL: https://issues.jboss.org/browse/ISPN-3599 > Project: Infinispan > Issue Type: Bug > Components: State transfer, Transactions > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Pedro Ruivo > Priority: Critical > Labels: jdg62GAblocker > Fix For: 6.0.0.CR2 > > > During state-transfer in tx cache, the node can receive {{CommitCommand}} from other node. After the node gets transaction data for affected segments, it creates the transaction with {{missingLookedUpEntries=true}} and the {{CommitCommand}} can be executed. > In this command's {{perform(...)}} the transaction is *first* marked as completed, then it enters the interceptor chain. There, the {{PrepareCommand}} is created in {{StateTransferInterceptor.visitCommitCommand}} but after this is processed the {{TxInterceptor}} finds out that the transaction is already completed and executes {{RollbackCommand}}, clearing locks etc. > Nevertheless, {{StateTransferInterceptor}} executes the initial {{CommitCommand}} afterwards. I suspect that this may be executed without the locks held. > Anyway, it is not correct to execute both commit and rollback on the same transaction. -- 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