[JBoss JIRA] (ISPN-3140) JMX operation to suppress state transfer
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3140?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3140:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 974402|https://bugzilla.redhat.com/show_bug.cgi?id=974402] from NEW to MODIFIED
> JMX operation to suppress state transfer
> ----------------------------------------
>
> Key: ISPN-3140
> URL: https://issues.jboss.org/browse/ISPN-3140
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Cache, State transfer
> Affects Versions: 5.2.6.Final
> Reporter: Manik Surtani
> Assignee: Dan Berindei
> Fix For: 5.2.7.Final, 5.3.0.CR2, 5.3.0.Final
>
>
> This feature request is to expose a JMX operation on each node, to suppress state transfer for a period of time. This flag would be {{false}} by default.
> The use case of this flag would be to ease bringing down (and up) a cluster for maintenance work. A typical workflow would be:
> 1) Shut down application requests to the data grid
> 2) Suppress state transfer on all nodes via JMX
> 3) Bring down all nodes
> 4) Perform maintenance work
> 5) Bring up nodes, one at a time. As each node comes up, disable state transfer for the node via JMX.
> 6) Once all nodes are up, enable state transfer for each node again via JMX
> 7) Allow application requests to reach the grid again.
> The purpose of this is to allow smooth and fast shutdown and startup, remove the risk of OOM errors (when bringing a grid down).
> This is a small but useful subset of full manual state transfer as defined in ISPN-1394.
--
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
10 years, 9 months
[JBoss JIRA] (ISPN-2863) org.infinispan.distexec.mapreduce.TopologyAwareTwoNodesMapReduceTest.testInvokeMapWithReduceExceptionPhaseInRemoteExecution
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2863?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2863:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 915831|https://bugzilla.redhat.com/show_bug.cgi?id=915831] from NEW to ASSIGNED
> org.infinispan.distexec.mapreduce.TopologyAwareTwoNodesMapReduceTest.testInvokeMapWithReduceExceptionPhaseInRemoteExecution
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2863
> URL: https://issues.jboss.org/browse/ISPN-2863
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Execution and Map/Reduce
> Affects Versions: 5.2.2.Final
> Environment: OracleJDK1.7, Solaris10Sparc x64
> Reporter: Vitalii Chepeliuk
> Assignee: Vladimir Blagojevic
> Labels: testsuite_stability
> Fix For: 6.0.0.Alpha1
>
>
> Error Message
> Method SimpleTwoNodesMapReduceTest.testInvokeMapWithReduceExceptionPhaseInRemoteExecution()[pri:0, instance:org.infinispan.distexec.mapreduce.TopologyAwareTwoNodesMapReduceTest@794d1a90] should have thrown an exception of class org.infinispan.CacheException
> Stacktrace
> org.testng.TestException:
> Method SimpleTwoNodesMapReduceTest.testInvokeMapWithReduceExceptionPhaseInRemoteExecution()[pri:0, instance:org.infinispan.distexec.mapreduce.TopologyAwareTwoNodesMapReduceTest@794d1a90] should have thrown an exception of class org.infinispan.CacheException
> at org.testng.internal.Invoker.handleInvocationResults(Invoker.java:1518)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:764)
> 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:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> 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)
> Standard Output
> [testng-TopologyAwareTwoNodesMapReduceTest] Test testInvokeMapWithReduceExceptionPhaseInRemoteExecution(org.infinispan.distexec.mapreduce.TopologyAwareTwoNodesMapReduceTest) failed.
> 2013-02-25 15:13:34,026 ERROR [UnitTestTestNGListener] (testng-TopologyAwareTwoNodesMapReduceTest) Test testInvokeMapWithReduceExceptionPhaseInRemoteExecution(org.infinispan.distexec.mapreduce.TopologyAwareTwoNodesMapReduceTest) failed.
> org.testng.TestException:
> Method SimpleTwoNodesMapReduceTest.testInvokeMapWithReduceExceptionPhaseInRemoteExecution()[pri:0, instance:org.infinispan.distexec.mapreduce.TopologyAwareTwoNodesMapReduceTest@794d1a90] should have thrown an exception of class org.infinispan.CacheException
> at org.testng.internal.Invoker.handleInvocationResults(Invoker.java:1518)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:764)
> 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:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> 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)
> Test suite progress: tests succeeded: 1680, failed: 1, skipped: 0.
--
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
10 years, 9 months
[JBoss JIRA] (ISPN-3013) CLI not supports slashes in name as "defaultx/xx"
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3013?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3013:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 952294|https://bugzilla.redhat.com/show_bug.cgi?id=952294] from NEW to ASSIGNED
> CLI not supports slashes in name as "defaultx/xx"
> --------------------------------------------------
>
> Key: ISPN-3013
> URL: https://issues.jboss.org/browse/ISPN-3013
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 5.2.4.Final
> Reporter: Vitalii Chepeliuk
> Assignee: Tristan Tarrant
> Priority: Minor
> Labels: cli
>
> When we connect from CLI to server. And configure our cache name to use / in names then name with slashes is correctly shown when we press <TAB> to autocomplete but If we choose this name of cache and press <ENTER> we get exception
> [remoting://localhost:9999/default/]> cache defaultx/xx
> java.lang.NullPointerException
> [remoting://localhost:9999/default/]> cache defaultx/xx
> java.lang.NullPointerException
> [remoting://localhost:9999/default/]> cache defaultx/xx
> java.lang.NullPointerException
> [remoting://localhost:9999/default/]> cache defaultx/xx
--
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
10 years, 9 months
[JBoss JIRA] (ISPN-3087) CLI HELP of some commands should to be changed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3087?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3087:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> made a comment on [bug 961317|https://bugzilla.redhat.com/show_bug.cgi?id=961317]
Fixed upstream
> CLI HELP of some commands should to be changed
> ----------------------------------------------
>
> Key: ISPN-3087
> URL: https://issues.jboss.org/browse/ISPN-3087
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 5.2.4.Final
> Environment: ALL
> Reporter: Vitalii Chepeliuk
> Assignee: Tristan Tarrant
> Labels: cli
> Fix For: 5.3.0.CR2
>
>
> Description of problem:
> Grammar mistakes in help of begin, connect, container, locate, put, replace, stats, upgrade commands should be fixed. Wrong words are wrapped in <<wrong word>>
> BEGIN COMMAND--------------------------------------------------------------------
> SYNOPSIS
> begin [cachename]
>
> DESCRIPTION
> Starts a transaction
>
> ARGUMENTS
> cachename
> (optional) the name of the cache on which to start the transaction. The currently selected cache will be used if this argument is <<missingThe>> cache must be transactional for
> this command to work
> CONNECT COMMAND------------------------------------------------------------------
> SYNOPSIS
> connect protocol://[user[:password]@]host][:port][/container[/cache]]
>
> DESCRIPTION
> Connects to an Infinispan instance using the specified protocol, host and port and with the supplied credentials.
>
> ARGUMENTS
> protocol
> currently only the jmx and the remoting (JMX over JBoss Remoting) protocols are supported. The jmxprotocol should be used to connect to directly over the standard JMX
> protocol, whereas <<theremotingprotocol>> should be used to connect to an Infinispan instance managed within an AS/EAP/JDG-style container.
> user (optional)
> The username to use when connecting if the server requires credentials
> password (optional)
> The password to use when connecting if the server requires credentials. When omitted, the password will be asked for interactively
> host
> the host name or IP address where the Infinispan instance is running
> port
> the port to connect to. For <<theremotingprotocol>> this defaults to 9999
> container (optional)
> the cache container to connect to by default. If unspecified, the first cache container will be selected
> cache (optional)
> the cache to connect to by default. If unspecified, no cache will be selected
> CONTAINER COMMAND---------------------------------------------------------------
> SYNOPSIS
> container [containername]
>
> DESCRIPTION
> Shows the available containers or selects a container to be used as default for CLI operations
>
> ARGUMENTS
> <<cachename>>
> (optional) the name of the container to set as default for the following operations
> LOCATE COMMAND------------------------------------------------------------------
> SYNOPSIS
> locate [--codec=codec] [cache.]key
>
> DESCRIPTION
> Shows the addresses of the owners in the cluster of the entry associated with the specified key. This command <<onlyworks>> for distributed caches
>
> ARGUMENTS
> cache
> (optional) the name of the cache to use. If not specified, the currently selected cache will be used. See the cache command
> key the key of the entry for which to show the address--codec=codec option has been specified then the key will be encoded using the specified codec, otherwise the default
> session codec will be used. See <<theencoding>> command for more information
> PUT COMMAND---------------------------------------------------------------------
> SYNOPSIS
> put [--codec=codec] [--ifabsent] [cache.]key value [expires expiration [maxidle idletime]]
>
> DESCRIPTION
> Associates the specified value with the specified key in this cache. If the cache previously contained a mapping for the key, the old value is replaced by the specified value.
> Optionally allows setting of a lifespan and a maximum idle time.
>
> ARGUMENTS
> cache
> the name of the cache where the key/value pair will be stored. If omitted uses the currently selected cache (see the <<cachecommand>>)
> key the key which identifies the element in the cache
> value
> the value to store in the cache associated with the keyIf the --codec=<<codecoption>> has been specified then the key and value will be encoded using the specified codec,
> otherwise the default session codec will be used. See <<theencodingcommand>> for more information
> expiration
> an optional expiration timeout (using the time value notation described below)
> idletime
> an optional idle timeout (using the time value notation described below)
>
> DATA TYPES
> The CLI understands the following types:
> string
> strings can either be quoted between single (') or double (") quotes, or left unquoted. In this case it must not contain spaces, punctuation and cannot begin with a number
> e.g. 'a string', key001
> int an integer is identified by a sequence of decimal digits, e.g. 256
> long
> a long is identified by a sequence of decimal digits suffixed by 'l', e.g. 1000l
> double
> a double precision number is identified by a floating point number(with optional exponent part) and an optional 'd' suffix, e.g.3.14
> float
> a single precision number is identified by a floating point number(with optional exponent part) and an 'f' suffix, e.g. 10.3f
> boolean
> a boolean is represented either by the keywords true and false
> UUID
> a UUID is represented by its canonical form XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
> JSON
> serialized Java classes can be represented using JSON notation, e.g. {"package.MyClass":{"i":5,"x":null,"b":true}}. Please note that the specified class must be available to
> the CacheManager's class loader.
>
> TIME VALUES
> A time value is an integer number followed by time unit suffix: days (d), hours (h), minutes (m), seconds (s), milliseconds (ms)
> REPLACE COMMAND-----------------------------------------------------------------
> See put command above
> UPGRADE COMMAND-----------------------------------------------------------------
> SYNOPSIS
> upgrade [--dumpkeys | --synchronize=migrator | --disconnectsource=migrator] [cachename | --all]
>
> DESCRIPTION
> This command performs operations used during the rolling upgrade procedure.
>
> ARGUMENTS
> --dumpkeys
> Performs the dump of all the keys in the cache to a known entry. It must be performed on the "source" cluster so that the "target" cluster can fetch the entire keyset
> efficiently to complete the synchronization operation
> --synchronize=migrator
> Performs the synchronization of all data from the "source" cluster to the "target" cluster using the specified migrator. It must be performed on the "target" cluster after
> the --dumpkeys operation has been performed on the "source" cluster. The only migrator currently available is hotrod which migrates entries between caches exposed via the
> HotRod remoting protocol.
> --disconnectsource=migrator
> Disconnects the "target" cluster from the "source" cluster. This is performed in a migrator-specific way. After this operation has been performed the "source" cluster can be
> switched off
> --all
> Specifies that the requested operation should be performed on all caches in the currently selected container
> cachename
> (optional) the name of the cache on which to invoke the specified upgrade command. If unspecified, the currently selected cache will be used. See also the --all switch above
>
> 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
> <<some space alignment needed here on 3. >>
> 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
>
--
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
10 years, 9 months