[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.Final
> 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, 6.0.0.Final
>
>
> 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
[JBoss JIRA] (ISPN-3613) Stored entries are deleted from table in rebalance
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3613?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3613:
--------------------------------
Fix Version/s: 6.0.0.CR2
6.0.0.Final
> Stored entries are deleted from table in rebalance
> --------------------------------------------------
>
> Key: ISPN-3613
> URL: https://issues.jboss.org/browse/ISPN-3613
> Project: Infinispan
> Issue Type: Bug
> Reporter: Mircea Markus
> Assignee: William Burns
> Labels: jdg62GAblocker
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> Description of problem:
> When passivation value is false, stored entries are deleted from table in rebalance.
> clustered.xml
> ------------
> <distributed-cache name="myCache" mode="SYNC" start="EAGER">
> <locking isolation="READ_COMMITTED" acquire-timeout="30000" concurrency-level="1000" striping="false"/>
> <transaction mode="NONE"/>
> <eviction strategy="LIRS" max-entries="10000"/>
> <string-keyed-jdbc-store datasource="java:jboss/datasources/InfinispanDS" passivation="false" preload="true" purge="false" shared="true" fetch-state="false">
> ...
> Version-Release number of selected component (if applicable):
> JDG 6.1
> How reproducible:
> I will attache the clustered.xml and trace logs.
> Steps to Reproduce:
> 1.start node1
> 2.put 300 entries
> 3.start node2
> check entries:
> select count(*) from table;
> 300
> 4.start node3
> check entries:
> select count(*) from table;
> 0
> Actual results:
> In step 4, number of entries are 0 in DB table.
> Expected results:
> In step 4, number of entries are 300 in DB table.
--
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
[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:
--------------------------------
Fix Version/s: 6.0.0.Final
> 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
> 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
[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:
--------------------------------
Assignee: Pedro Ruivo (was: Dan Berindei)
> 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
>
> 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
[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:
--------------------------------
Fix Version/s: 6.0.0.CR2
> 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
> Labels: jdg62GAblocker
> Fix For: 6.0.0.CR2
>
>
> 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
[JBoss JIRA] (ISPN-3376) CLI upgrade command does not work
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3376?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3376:
--------------------------------
Fix Version/s: 6.0.0.CR2
> CLI upgrade command does not work
> ---------------------------------
>
> Key: ISPN-3376
> URL: https://issues.jboss.org/browse/ISPN-3376
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 6.0.0.Alpha1
> Reporter: Vitalii Chepeliuk
> Assignee: Tristan Tarrant
> Labels: jdg62GAblocker
> Fix For: 6.0.0.CR2
>
> Attachments: logs.zip, standalone-hotrod-rolling-upgrade.xml
>
>
> Run my backup server with default standalone.xml configuration
> ./standalone.sh -c standalone.xml -Djboss.socket.binding.port-offset=111 -Djboss.node.name=BACKUPER
> Run my new server with
> ./standalone.sh -c standalone-hotrod-rolling-upgrade.xml -Djboss.node.name=UPGRADER
> 1) run command on BACKUPER
> [remoting://localhost:10110/local/default]> upgrade --dumpkeys default
> ISPN019502: Dumped keys for cache default
> 2) run command on UPGRADER
> [remoting://localhost:9999/local/default]> upgrade --synchronize=hotrod default
> ISPN019026: An error occurred while synchronizing data for cache 'hotrod' using migrator 'default' from the source server
--
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
[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.CR2
> 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
>
> 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
[JBoss JIRA] (ISPN-3598) ISPN testsuite fails for RHEL 5, 6 && IBM JDK6
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3598?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3598:
--------------------------------
Fix Version/s: 6.0.0.CR2
> ISPN testsuite fails for RHEL 5,6 && IBM JDK6
> ---------------------------------------------
>
> Key: ISPN-3598
> URL: https://issues.jboss.org/browse/ISPN-3598
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.Beta1
> Environment: RHEL{5, 6} && IBM JDK6
> Reporter: Anna Manukyan
> Assignee: William Burns
> Labels: jdg62GAblocker, testsuite_stability
> Fix For: 6.0.0.CR2
>
> Attachments: ibm6_infinispan_failure_rhel5_x32.log, ibm6_infinispan_failure_rhel5_x64.log, ibm6_infinispan_failure_rhel6_x32.log, ibm6_infinispan_failure_rhel6_x64.log
>
>
> The ISPN testsuite fails for the environment specified in the description.
> You can find the core module's tracelog for all configurations attached.
--
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