[JBoss JIRA] (ISPN-3323) Update Hotrod client version number
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3323?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-3323:
-------------------------------------
Assignee: Tristan Tarrant (was: Mircea Markus)
> Update Hotrod client version number
> -----------------------------------
>
> Key: ISPN-3323
> URL: https://issues.jboss.org/browse/ISPN-3323
> Project: Infinispan
> Issue Type: Task
> Components: Remote protocols
> Affects Versions: 5.3.0.Final
> Reporter: Dan Berindei
> Assignee: Tristan Tarrant
> Fix For: 6.0.0.Final
>
>
> {{BasicCache.getVersion()}} is documented to return "the version of Infinispan", but {{RemoteCacheImpl.getVersion()}} returns {{Version.getProtocolVersion()}} (which is {{"1.0"}}).
> I think there should be a separate method to return the protocol version, and {{RemoteCacheImpl.getVersion()}} should return the Infinispan version (with a hook in the release script to update it automatically).
> {{Version.getProtocolVersion()}} should also be updated to {{"1.2"}}.
--
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, 1 month
[JBoss JIRA] (ISPN-3357) Insufficient owners with putIfAbsent during node join rebalance
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3357?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-3357:
-------------------------------------
Good analysis Takayoshi.
{quote} node4 performed clustered get before write, got a value from node2 and will not commit the entry because this node thinks it's not changed/created {quote}
Indeed this is a race condition. When the PutIfAbsentCommand is forwarded from n2 to n4 it should also contain the existing value as seen by n2 (currently owner) or set the PutKeyValueCommand.ignorePreviousValue before forwarding the command to the remote node.
Note that this problem also applies to other conditional commands (replace, remove)
> Insufficient owners with putIfAbsent during node join rebalance
> ---------------------------------------------------------------
>
> Key: ISPN-3357
> URL: https://issues.jboss.org/browse/ISPN-3357
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.4.Final, 6.0.0.Alpha1
> Reporter: Takayoshi Kimura
> Assignee: Dan Berindei
> Priority: Critical
> Attachments: 7c29bccb.log
>
>
> Here is test scenario:
> * DIST numOwners=2, start with 3 nodes cluster then join 1 node during load
> * HotRod putIfAbsent accesses from 40 threads (1 process, 1 remote cache instance), 40000 entries total
> After the test run, the numberOfEntries on each node are:
> * node1: 20074
> * node2: 19888
> * node3: 20114
> * node4: 18885
> Total is 78961, 1039 entries are missing. No error on HotRod client side so 80000 entries should be there.
> Let's take a look at example missing entry, hash(thread01key151) = 7c29bccb.
> Current CH: owners(7c29bccb) are [node1, node2]
> Pending CH: owners(7c29bccb) are [node1, node2, node4]
> Balanced CH: owners(7c29bccb) are [node1, node4]
> The events sequence is:
> * hotrod -> node1
> * node1 -> node2, node4
> * node2 committed entry
> * node4 performed clustered get before write, got a value from node2 and will not commit the entry because this node thinks it's not changed/created
> * node1 committed entry
> * node2 invalidates the entry because it's no longer an owner
> Result owners(7c29bccb) are only node1 and node4 is missing. This entry may be completely lost by further rebalances when node4 is donor for this segment.
--
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, 1 month
[JBoss JIRA] (ISPN-3365) org.infinispan.lucene.DatabaseStoredIndexTest.indexWasStored fails with AssertionError
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3365?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3365:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1988
> org.infinispan.lucene.DatabaseStoredIndexTest.indexWasStored fails with AssertionError
> --------------------------------------------------------------------------------------
>
> Key: ISPN-3365
> URL: https://issues.jboss.org/browse/ISPN-3365
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 6.0.0.Alpha1
> Environment: RHEL5_x86_64, IBMJDK1.7
> Reporter: Vitalii Chepeliuk
> Assignee: Sanne Grinovero
> Labels: testsuite_stability
> Attachments: infinispan-lucene-v3.log.zip
>
>
> Stacktrace
> java.lang.AssertionError:
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:41)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:49)
> at org.infinispan.lucene.DatabaseStoredIndexTest.indexWasStored(DatabaseStoredIndexTest.java:111)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:613)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:345)
> at java.util.concurrent.FutureTask.run(FutureTask.java:177)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626)
> at java.lang.Thread.run(Thread.java:780)
> Standard Output
> Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:_3.fdt|RL|testing index
> Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:_3.tis|RL|testing index
> Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:segments_4|RL|testing index
> Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:_3.nrm|RL|testing index
> Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:_3.prx|RL|testing index
> Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:_3.fdx|RL|testing index
> [testng-DatabaseStoredIndexTest] Test indexWasStored(org.infinispan.lucene.DatabaseStoredIndexTest) failed.
> Add link to jenkins job https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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, 1 month
[JBoss JIRA] (ISPN-3352) Issues with the M/Rs intermediate cache shut down
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3352?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3352:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Issues with the M/Rs intermediate cache shut down
> -------------------------------------------------
>
> Key: ISPN-3352
> URL: https://issues.jboss.org/browse/ISPN-3352
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Execution and Map/Reduce
> Affects Versions: 5.3.0.Final
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Fix For: 6.0.0.Alpha2, 6.0.0.Final
>
>
> The intermediate cache that is created for a distributed map/reduce phase calls cache.clear() before shutting down. This is a distributed call and might result in a timeout given that some of the cache instances on remote nodes are shutting down whilst processing the clear response.
> This clear invocation should be local.
--
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, 1 month
[JBoss JIRA] (ISPN-3272) Help of Put, Replace, Rollback, Start CLI commands got StringIndexOutOfBoundsException
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3272?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3272:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1987
> Help of Put, Replace, Rollback, Start CLI commands got StringIndexOutOfBoundsException
> --------------------------------------------------------------------------------------
>
> Key: ISPN-3272
> URL: https://issues.jboss.org/browse/ISPN-3272
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 5.3.0.Final
> Reporter: Vitalii Chepeliuk
> Assignee: Tristan Tarrant
> Fix For: 6.0.0.Final
>
>
> When want to run commands---------------------------------------------
> >>>1. ispn-cli.sh -f put.sc
> >>>2. ispn-cli.sh -f replace.sc
> >>>3. ispn-cli.sh -f rollback.sc
> >>>4. ispn-cli.sh -f start.sc
> cat put.sc------------------------------------------------------------
> help put
> cat replace.sc--------------------------------------------------------
> help replace
> cat rollback.sc-------------------------------------------------------
> help rollback
> cat start.sc----------------------------------------------------------
> help start
> Exception is thrown outside JConsole shell----------------------------
> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.charAt(String.java:658)
> at org.infinispan.cli.shell.Man2Ansi.fit(Man2Ansi.java:108)
> at org.infinispan.cli.shell.Man2Ansi.render(Man2Ansi.java:78)
> at org.infinispan.cli.commands.client.Help.execute(Help.java:67)
> at org.infinispan.cli.shell.ShellImpl.execute(ShellImpl.java:181)
> at org.infinispan.cli.shell.ShellImpl.batchRun(ShellImpl.java:136)
> at org.infinispan.cli.shell.ShellImpl.run(ShellImpl.java:123)
> at org.infinispan.cli.Main.main(Main.java:41)
> 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.jboss.modules.Module.run(Module.java:262)
> at org.jboss.modules.Main.main(Main.java:329)
> Other errors inside jconsole shell------------------------------------
> run command: ispn-cli.sh -
> [disconnected//]> help rollback
> String index out of range: -1
> [disconnected//]> help start
> String index out of range: -1
> >>>5. help upgrade, 3rd paragraph in USAGE is not aligned
> USAGE
> In order to perform a rolling upgrade of a HotRod cluster, the following steps must be taken
> 1. Configure and start a new cluster with a RemoteCacheStore pointing to the old cluster and the
> hotRodWrapping flag enabled
> 2. Configure all clients so that they will connect to the new cluster
> 3. Invoke the
> upgrade --dumpkeys command on the old cluster for all of the caches that need to be migrated
> 4. Invoke the
> upgrade --synchronize=hotrod command on the new cluster to ensure that all data is migrated from the old cluster to the new one
> 5. Invoke the
> upgrade --disconnectsource=hotrod command on the new cluster to disable the RemoteCacheStore used to migrate the data
> 6. Switch off the old cluster
> >>>6. help container, wrong argument
> SYNOPSIS
> container [ containername ]
>
> DESCRIPTION
> Shows the available containers or selects a container to be used as default for CLI operations
>
> ARGUMENTS
> cachename <<<<<<<<<<<<<, here should be container name and not cache name
> (optional) the name of the container to set as default for the following operations
--
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, 1 month
[JBoss JIRA] (ISPN-3223) HotRod Client recieves stale toplogy view on instance leave
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3223?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3223:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=988675
> HotRod Client recieves stale toplogy view on instance leave
> -----------------------------------------------------------
>
> Key: ISPN-3223
> URL: https://issues.jboss.org/browse/ISPN-3223
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 5.2.4.Final, 5.3.0.CR1
> Reporter: Takayoshi Kimura
> Assignee: Galder Zamarreño
> Fix For: 6.0.0.Final
>
>
> When killed a HotRod server node, HotRod Clinet sometimes recieves a stale toplogy view which includes the dead node and uses it as a latest view. In this case the client keeps trying to connect that node and keeps failing.
> Looks like the AbstractEncoder1x.generateTopologyResponse() takes care of node join but doesn't handle node leave:
> {noformat}
> if (!serverEndpointsMap.keySet.containsAll(cacheMembers)) {
> {noformat}
> For example, serverEndpointsMap.keySet is [A, B, C] and the actual cacheMembers is [A, B].
--
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, 1 month
[JBoss JIRA] (ISPN-3223) HotRod Client recieves stale toplogy view on instance leave
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3223?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3223:
-----------------------------------------------
Takayoshi Kimura <tkimura(a)redhat.com> made a comment on [bug 988675|https://bugzilla.redhat.com/show_bug.cgi?id=988675]
Product ticket for ISPN-3223
> HotRod Client recieves stale toplogy view on instance leave
> -----------------------------------------------------------
>
> Key: ISPN-3223
> URL: https://issues.jboss.org/browse/ISPN-3223
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 5.2.4.Final, 5.3.0.CR1
> Reporter: Takayoshi Kimura
> Assignee: Galder Zamarreño
> Fix For: 6.0.0.Final
>
>
> When killed a HotRod server node, HotRod Clinet sometimes recieves a stale toplogy view which includes the dead node and uses it as a latest view. In this case the client keeps trying to connect that node and keeps failing.
> Looks like the AbstractEncoder1x.generateTopologyResponse() takes care of node join but doesn't handle node leave:
> {noformat}
> if (!serverEndpointsMap.keySet.containsAll(cacheMembers)) {
> {noformat}
> For example, serverEndpointsMap.keySet is [A, B, C] and the actual cacheMembers is [A, B].
--
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, 1 month
[JBoss JIRA] (ISPN-3223) HotRod Client recieves stale toplogy view on instance leave
by Takayoshi Kimura (JIRA)
[ https://issues.jboss.org/browse/ISPN-3223?page=com.atlassian.jira.plugin.... ]
Takayoshi Kimura updated ISPN-3223:
-----------------------------------
Summary: HotRod Client recieves stale toplogy view on instance leave (was: HotRod Clinet recieves stale toplogy view on instance leave)
> HotRod Client recieves stale toplogy view on instance leave
> -----------------------------------------------------------
>
> Key: ISPN-3223
> URL: https://issues.jboss.org/browse/ISPN-3223
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 5.2.4.Final, 5.3.0.CR1
> Reporter: Takayoshi Kimura
> Assignee: Galder Zamarreño
> Fix For: 6.0.0.Final
>
>
> When killed a HotRod server node, HotRod Clinet sometimes recieves a stale toplogy view which includes the dead node and uses it as a latest view. In this case the client keeps trying to connect that node and keeps failing.
> Looks like the AbstractEncoder1x.generateTopologyResponse() takes care of node join but doesn't handle node leave:
> {noformat}
> if (!serverEndpointsMap.keySet.containsAll(cacheMembers)) {
> {noformat}
> For example, serverEndpointsMap.keySet is [A, B, C] and the actual cacheMembers is [A, B].
--
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, 1 month
[JBoss JIRA] (ISPN-3369) ParserRegistry throws exception when DefaultCacheManager is using config file
by Emre Varol (JIRA)
Emre Varol created ISPN-3369:
--------------------------------
Summary: ParserRegistry throws exception when DefaultCacheManager is using config file
Key: ISPN-3369
URL: https://issues.jboss.org/browse/ISPN-3369
Project: Infinispan
Issue Type: Bug
Components: Configuration
Affects Versions: 6.0.0.Alpha1
Reporter: Emre Varol
Assignee: Mircea Markus
Priority: Blocker
ParserRegistiry throws an exception with message "ISPN000234: Root element for remoteStore already registered in ParserRegistry" when DefaultCacheManager is created with a config file.
It is because BdbjeCacheStoreConfigurationParser60 has wrong namespace annotation. In line 27, "remoteStore" should be replaced with "bdbjeStore".
--
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, 1 month