[JBoss JIRA] (ISPN-2965) L1 and early invalidation leaves inconsistent state
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2965?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2965:
-------------------------------------
Here is a L1 inconsistency window (needs to be proved with a unit test):
- B owns k
- tx1 on A reads k, keeps it in its tx context
- C updates k, B invalidates all the readers (potentially including A)
- B commits and writes old k's value in L1
> L1 and early invalidation leaves inconsistent state
> ---------------------------------------------------
>
> Key: ISPN-2965
> URL: https://issues.jboss.org/browse/ISPN-2965
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Transactions
> Affects Versions: 5.2.1.Final
> Reporter: Sebastian Tusk
> Assignee: William Burns
> Labels: 5.2.x
> Fix For: 5.3.0.Final
>
>
> In a distributed transactional cache with L1 enabled I can observe the following.
> Prepare cache by adding an entry with Cache.put( k, v1 ).
> 1. Node B starts with adding a changed value. Cache.put( k, v2 )
> 2. Node B TxDistributionInterceptor.visitPrepareCommand flushL1Caches sends invalidations.
> 3. Node A calls Cache.get( k ) retrieves v1 and stores this value in L1.
> 4. Node B proceeds with transaction.
> The result is that Node A answers subsequent Cache.get(k) with v1 and Node B answers with v2.
> It seems the invalidation is either send to early or must be synchronized in some way with the transaction.
> Cache config:
> <namedCache name="entity">
> <jmxStatistics enabled="true" />
> <clustering mode="dist">
> <stateTransfer fetchInMemoryState="false" timeout="20000" />
> <async />
> <l1 enabled="true" />
> <hash numOwners="1"/>
> </clustering>
> <locking isolationLevel="READ_COMMITTED"
> lockAcquisitionTimeout="15000" useLockStriping="false" />
> <eviction maxEntries="10000" strategy="LRU" />
> <expiration maxIdle="100000" wakeUpInterval="5000"/>
> <storeAsBinary storeKeysAsBinary="true" storeValuesAsBinary="false" enabled="false" />
> <transaction transactionMode="TRANSACTIONAL" autoCommit="false" lockingMode="OPTIMISTIC"/>
> </namedCache>
--
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, 7 months
[JBoss JIRA] (ISPN-2836) org.jgroups.TimeoutException after invoking MapCombineCommand in Map/Reduce task with 2 nodes
by Alan Field (JIRA)
[ https://issues.jboss.org/browse/ISPN-2836?page=com.atlassian.jira.plugin.... ]
Alan Field commented on ISPN-2836:
----------------------------------
offtopic: Ok, sorry and I'll look at my encoding code again.
The machines in the JDG performance lab are using a 4GB heap, but the OOM error is happening in MapReduceTask.execute() before the result map is put into the cache. (Step #3) I agree with you that writing the file contents as String values will take more memory though. I can try these tests with a random data generator that uses an exact number of bytes as well, so that the data is actually what is expected.
> org.jgroups.TimeoutException after invoking MapCombineCommand in Map/Reduce task with 2 nodes
> ---------------------------------------------------------------------------------------------
>
> Key: ISPN-2836
> URL: https://issues.jboss.org/browse/ISPN-2836
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Execution and Map/Reduce
> Affects Versions: 5.2.1.Final
> Reporter: Alan Field
> Assignee: Pedro Ruivo
> Priority: Blocker
> Labels: onboard
> Fix For: 5.3.0.Final
>
> Attachments: afield-tcp-521-final.txt, benchmark-mapreduce-multifilesize.xml, dist-udp-no-tx.xml, jgroups-udp.xml, udp-edg-perf01.txt, udp-edg-perf02.txt
>
>
> Using RadarGun and two nodes to execute the example WordCount Map/Reduce job against a cache with ~550 keys with a value size of 1MB is producing a thread deadlock. The cache is distributed with transactions disabled.
> TCP transport deadlocks without throwing an exception. Disabling the send queue and setting UNICAST2.conn_expiry_timeout=0 prevents the deadlock, but the job does not complete. The nodes send "are-you-alive" messages back and forth, and I have seen the following exception:
> {noformat}
> 11:44:29,970 ERROR [org.jgroups.protocols.TCP] (OOB-98,default,edg-perf01-1907) failed sending message to edg-perf02-32536 (76 bytes): java.net.SocketException: Socket closed, cause: null
> at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:352)
> at org.radargun.cachewrappers.InfinispanMapReduceWrapper.executeMapReduceTask(InfinispanMapReduceWrapper.java:98)
> at org.radargun.stages.MapReduceStage.executeOnSlave(MapReduceStage.java:74)
> at org.radargun.Slave$2.run(Slave.java:103)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to edg-perf02-32536
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
> at java.util.concurrent.FutureTask.get(FutureTask.java:83)
> at org.infinispan.distexec.mapreduce.MapReduceTask$TaskPart.get(MapReduceTask.java:832)
> at org.infinispan.distexec.mapreduce.MapReduceTask.executeMapPhaseWithLocalReduction(MapReduceTask.java:477)
> at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:350)
> ... 9 more
> Caused by: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to edg-perf02-32536
> at org.infinispan.util.Util.rewrapAsCacheException(Util.java:541)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:186)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:515)
> 11:44:29,978 ERROR [org.jgroups.protocols.TCP] (Timer-3,default,edg-perf01-1907) failed sending message to edg-perf02-32536 (60 bytes): java.net.SocketException: Socket closed, cause: null
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:175)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:197)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:254)
> at org.infinispan.remoting.rpc.RpcManagerImpl.access$000(RpcManagerImpl.java:80)
> at org.infinispan.remoting.rpc.RpcManagerImpl$1.call(RpcManagerImpl.java:288)
> ... 5 more
> Caused by: org.jgroups.TimeoutException: timeout sending message to edg-perf02-32536
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:390)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:301)
> 11:44:29,979 ERROR [org.jgroups.protocols.TCP] (Timer-4,default,edg-perf01-1907) failed sending message to edg-perf02-32536 (63 bytes): java.net.SocketException: Socket closed, cause: null
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:179)
> ... 11 more
> {noformat}
> With UDP transport, both threads are deadlocked. I will attach thread dumps from runs using TCP and UDP transport.
--
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, 7 months
[JBoss JIRA] (ISPN-2836) org.jgroups.TimeoutException after invoking MapCombineCommand in Map/Reduce task with 2 nodes
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2836?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-2836:
-----------------------------------
offtopic: I had to change you LoadFileStage to fix the encode problem. I have now this line:
String cacheData = Charset.forName("ISO-8859-1").decode(buffer).toString();
How much is your heap space?
Remember that each char in Java is 2 bytes. 1GB file will take 2GB of heap and the map-reduce creates a bunch of copies:
#1) load all file to the cache
#2) the map phase will create a new cache with {word => list<int>(with counter in each node)} (+- the file size)
#3) the reduce phase will create a new map with {word => sum of all counters} (+- the file size)
#4) the result is put back in the cache (cacheWrapper.put(null, MAPREDUCE_RESULT_KEY, payloadMap);)
I would say that you may need at least 6GB of heap space for larger files (1GB).
> org.jgroups.TimeoutException after invoking MapCombineCommand in Map/Reduce task with 2 nodes
> ---------------------------------------------------------------------------------------------
>
> Key: ISPN-2836
> URL: https://issues.jboss.org/browse/ISPN-2836
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Execution and Map/Reduce
> Affects Versions: 5.2.1.Final
> Reporter: Alan Field
> Assignee: Pedro Ruivo
> Priority: Blocker
> Labels: onboard
> Fix For: 5.3.0.Final
>
> Attachments: afield-tcp-521-final.txt, benchmark-mapreduce-multifilesize.xml, dist-udp-no-tx.xml, jgroups-udp.xml, udp-edg-perf01.txt, udp-edg-perf02.txt
>
>
> Using RadarGun and two nodes to execute the example WordCount Map/Reduce job against a cache with ~550 keys with a value size of 1MB is producing a thread deadlock. The cache is distributed with transactions disabled.
> TCP transport deadlocks without throwing an exception. Disabling the send queue and setting UNICAST2.conn_expiry_timeout=0 prevents the deadlock, but the job does not complete. The nodes send "are-you-alive" messages back and forth, and I have seen the following exception:
> {noformat}
> 11:44:29,970 ERROR [org.jgroups.protocols.TCP] (OOB-98,default,edg-perf01-1907) failed sending message to edg-perf02-32536 (76 bytes): java.net.SocketException: Socket closed, cause: null
> at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:352)
> at org.radargun.cachewrappers.InfinispanMapReduceWrapper.executeMapReduceTask(InfinispanMapReduceWrapper.java:98)
> at org.radargun.stages.MapReduceStage.executeOnSlave(MapReduceStage.java:74)
> at org.radargun.Slave$2.run(Slave.java:103)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to edg-perf02-32536
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
> at java.util.concurrent.FutureTask.get(FutureTask.java:83)
> at org.infinispan.distexec.mapreduce.MapReduceTask$TaskPart.get(MapReduceTask.java:832)
> at org.infinispan.distexec.mapreduce.MapReduceTask.executeMapPhaseWithLocalReduction(MapReduceTask.java:477)
> at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:350)
> ... 9 more
> Caused by: org.infinispan.CacheException: org.jgroups.TimeoutException: timeout sending message to edg-perf02-32536
> at org.infinispan.util.Util.rewrapAsCacheException(Util.java:541)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:186)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:515)
> 11:44:29,978 ERROR [org.jgroups.protocols.TCP] (Timer-3,default,edg-perf01-1907) failed sending message to edg-perf02-32536 (60 bytes): java.net.SocketException: Socket closed, cause: null
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:175)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:197)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:254)
> at org.infinispan.remoting.rpc.RpcManagerImpl.access$000(RpcManagerImpl.java:80)
> at org.infinispan.remoting.rpc.RpcManagerImpl$1.call(RpcManagerImpl.java:288)
> ... 5 more
> Caused by: org.jgroups.TimeoutException: timeout sending message to edg-perf02-32536
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:390)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:301)
> 11:44:29,979 ERROR [org.jgroups.protocols.TCP] (Timer-4,default,edg-perf01-1907) failed sending message to edg-perf02-32536 (63 bytes): java.net.SocketException: Socket closed, cause: null
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:179)
> ... 11 more
> {noformat}
> With UDP transport, both threads are deadlocked. I will attach thread dumps from runs using TCP and UDP transport.
--
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, 7 months
[JBoss JIRA] (ISPN-2965) L1 and early invalidation leaves inconsistent state
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2965?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2965:
--------------------------------
Assignee: William Burns (was: Adrian Nistor)
> L1 and early invalidation leaves inconsistent state
> ---------------------------------------------------
>
> Key: ISPN-2965
> URL: https://issues.jboss.org/browse/ISPN-2965
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, Transactions
> Affects Versions: 5.2.1.Final
> Reporter: Sebastian Tusk
> Assignee: William Burns
> Labels: 5.2.x
> Fix For: 5.3.0.Final
>
>
> In a distributed transactional cache with L1 enabled I can observe the following.
> Prepare cache by adding an entry with Cache.put( k, v1 ).
> 1. Node B starts with adding a changed value. Cache.put( k, v2 )
> 2. Node B TxDistributionInterceptor.visitPrepareCommand flushL1Caches sends invalidations.
> 3. Node A calls Cache.get( k ) retrieves v1 and stores this value in L1.
> 4. Node B proceeds with transaction.
> The result is that Node A answers subsequent Cache.get(k) with v1 and Node B answers with v2.
> It seems the invalidation is either send to early or must be synchronized in some way with the transaction.
> Cache config:
> <namedCache name="entity">
> <jmxStatistics enabled="true" />
> <clustering mode="dist">
> <stateTransfer fetchInMemoryState="false" timeout="20000" />
> <async />
> <l1 enabled="true" />
> <hash numOwners="1"/>
> </clustering>
> <locking isolationLevel="READ_COMMITTED"
> lockAcquisitionTimeout="15000" useLockStriping="false" />
> <eviction maxEntries="10000" strategy="LRU" />
> <expiration maxIdle="100000" wakeUpInterval="5000"/>
> <storeAsBinary storeKeysAsBinary="true" storeValuesAsBinary="false" enabled="false" />
> <transaction transactionMode="TRANSACTIONAL" autoCommit="false" lockingMode="OPTIMISTIC"/>
> </namedCache>
--
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, 7 months
[JBoss JIRA] (ISPN-3161) ClusterFileCacheStoreFunctionalTest.testRestoreTransactionalAtomicMap fails intermittently
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3161?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3161:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1880
> ClusterFileCacheStoreFunctionalTest.testRestoreTransactionalAtomicMap fails intermittently
> ------------------------------------------------------------------------------------------
>
> Key: ISPN-3161
> URL: https://issues.jboss.org/browse/ISPN-3161
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores, Test Suite
> Affects Versions: 5.3.0.CR1
> Reporter: William Burns
> Assignee: Mircea Markus
> Attachments: infinispan.zip
>
>
> This test fails intermittently with a TimeoutException.
> The easiest way to reproduce is just to add an @Test annotation setting the invocationCount to 1000 or more.
> I have attached a trace when the error occurs.
> {code}
> 2013-05-30 17:27:41,660 ERROR (main) [org.infinispan.interceptors.InvocationContextInterceptor] ISPN000136: Execution error
> org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [0 milliseconds] on key [testRestoreTransactionalAtomicMap] for requestor [Thread[main,5,main]]! Lock held by [GlobalTransaction:<NodeA-52943>:700:remote]
> at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:214)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLockNoCheck(LockManagerImpl.java:197)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockKey(AbstractLockingInterceptor.java:149)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.visitEvictCommand(AbstractTxLockingInterceptor.java:86)
> at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:49)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:134)
> at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:79)
> at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:49)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:134)
> at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:79)
> at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:49)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:134)
> at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:79)
> at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:49)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitEvictCommand(StateTransferInterceptor.java:179)
> at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:49)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitEvictCommand(AbstractVisitor.java:79)
> at org.infinispan.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:49)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> at org.infinispan.CacheImpl.evict(CacheImpl.java:538)
> at org.infinispan.CacheImpl.evict(CacheImpl.java:531)
> at org.infinispan.loaders.file.ClusterFileCacheStoreFunctionalTest.testRestoreTransactionalAtomicMap(ClusterFileCacheStoreFunctionalTest.java:101)
> ....
> {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, 7 months
[JBoss JIRA] (ISPN-2823) TransactionManagerLookup is silently ignored with invocation batching
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2823?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2823:
------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.3.0.CR2
(was: 5.3.0.Final)
Resolution: Done
> TransactionManagerLookup is silently ignored with invocation batching
> ---------------------------------------------------------------------
>
> Key: ISPN-2823
> URL: https://issues.jboss.org/browse/ISPN-2823
> Project: Infinispan
> Issue Type: Bug
> Components: Core API, Transactions
> Affects Versions: 5.2.0.Final, 5.2.1.Final
> Reporter: Jeremy Stone
> Assignee: Tristan Tarrant
> Fix For: 5.3.0.CR2
>
> Attachments: infinispan_batch_tx.zip
>
>
> A configured TransactionManagerLookup is ignored when invocation batching is enabled.
> Attempts to put an entry into the cache are greeted with "java.lang.IllegalStateException: This is a tx cache!" despite the presence of an active transaction.
> This seems to make it impossible to use the Tree API, where invocation batch mode is mandatory, in a transactional environment.
--
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, 7 months
[JBoss JIRA] (ISPN-3087) CLI HELP of some commands should to be changed
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3087?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3087:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.3.0.CR2
Resolution: Done
> 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
11 years, 7 months