[JBoss JIRA] (ISPN-3088) Put long values from CLI, raise java.lang.NumberFormatException: For input string: "1000l" on server
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3088?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3088:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=961334
> Put long values from CLI, raise java.lang.NumberFormatException: For input string: "1000l" on server
> ----------------------------------------------------------------------------------------------------
>
> Key: ISPN-3088
> URL: https://issues.jboss.org/browse/ISPN-3088
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 5.2.4.Final
> Environment: ALL
> Reporter: Vitalii Chepeliuk
> Assignee: Tristan Tarrant
> Labels: cli
>
> From "help put" in CLI we get that a long is identified by a sequence of decimal digits suffixed by 'l', e.g. 1000l
> But when put some data to cache e.g put num 1000l we get follow message on client side------------------------------------------------------------------
> [remoting://localhost:9999/local/default]> put num 1000l
> For input string: "1000l"
> And exception on server side-------------------------------------------------------------------------------------------------------------------
> 14:17:23,179 ERROR [org.infinispan.cli.interpreter.Interpreter] (pool-1-thread-1) ISPN019003: Interpreter error: java.lang.NumberFormatException: For input string: "1000l"
> at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.7.0_17]
> at java.lang.Long.parseLong(Long.java:441) [rt.jar:1.7.0_17]
> at java.lang.Long.valueOf(Long.java:540) [rt.jar:1.7.0_17]
> at org.infinispan.cli.interpreter.IspnQLParser.literal(IspnQLParser.java:3791) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at org.infinispan.cli.interpreter.IspnQLParser.putStatement(IspnQLParser.java:2147) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at org.infinispan.cli.interpreter.IspnQLParser.statement(IspnQLParser.java:689) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at org.infinispan.cli.interpreter.IspnQLParser.statements(IspnQLParser.java:237) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:157) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) [:1.7.0_17]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_17]
> at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:287) [infinispan-core-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) [rt.jar:1.7.0_17]
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792) [rt.jar:1.7.0_17]
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:498) [jboss-as-jmx-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:246) [jboss-as-jmx-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
> at org.jboss.remotingjmx.protocol.v1.ServerProxy$InvokeHandler.handle(ServerProxy.java:1034)
> at org.jboss.remotingjmx.protocol.v1.ServerProxy$MessageReciever$1.run(ServerProxy.java:215)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
--
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, 2 months
[JBoss JIRA] (ISPN-3088) Put long values from CLI, raise java.lang.NumberFormatException: For input string: "1000l" on server
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3088?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3088:
-----------------------------------------------
Vitalii Chepeliuk <vchepeli(a)redhat.com> made a comment on [bug 961334|https://bugzilla.redhat.com/show_bug.cgi?id=961334]
>From "help put" in CLI we get that a long is identified by a sequence of decimal digits suffixed by 'l', e.g. 1000l
But when put some data to cache e.g put num 1000l we get follow message on client side------------------------------------------------------------------
[remoting://localhost:9999/local/default]> put num 1000l
For input string: "1000l"
And exception on server side-------------------------------------------------------------------------------------------------------------------
14:17:23,179 ERROR [org.infinispan.cli.interpreter.Interpreter] (pool-1-thread-1) ISPN019003: Interpreter error: java.lang.NumberFormatException: For input string: "1000l"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.7.0_17]
at java.lang.Long.parseLong(Long.java:441) [rt.jar:1.7.0_17]
at java.lang.Long.valueOf(Long.java:540) [rt.jar:1.7.0_17]
at org.infinispan.cli.interpreter.IspnQLParser.literal(IspnQLParser.java:3791) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at org.infinispan.cli.interpreter.IspnQLParser.putStatement(IspnQLParser.java:2147) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at org.infinispan.cli.interpreter.IspnQLParser.statement(IspnQLParser.java:689) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at org.infinispan.cli.interpreter.IspnQLParser.statements(IspnQLParser.java:237) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:157) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) [:1.7.0_17]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_17]
at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_17]
at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:287) [infinispan-core-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) [rt.jar:1.7.0_17]
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792) [rt.jar:1.7.0_17]
at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:498) [jboss-as-jmx-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:246) [jboss-as-jmx-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
at org.jboss.remotingjmx.protocol.v1.ServerProxy$InvokeHandler.handle(ServerProxy.java:1034)
at org.jboss.remotingjmx.protocol.v1.ServerProxy$MessageReciever$1.run(ServerProxy.java:215)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> Put long values from CLI, raise java.lang.NumberFormatException: For input string: "1000l" on server
> ----------------------------------------------------------------------------------------------------
>
> Key: ISPN-3088
> URL: https://issues.jboss.org/browse/ISPN-3088
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 5.2.4.Final
> Environment: ALL
> Reporter: Vitalii Chepeliuk
> Assignee: Tristan Tarrant
> Labels: cli
>
> From "help put" in CLI we get that a long is identified by a sequence of decimal digits suffixed by 'l', e.g. 1000l
> But when put some data to cache e.g put num 1000l we get follow message on client side------------------------------------------------------------------
> [remoting://localhost:9999/local/default]> put num 1000l
> For input string: "1000l"
> And exception on server side-------------------------------------------------------------------------------------------------------------------
> 14:17:23,179 ERROR [org.infinispan.cli.interpreter.Interpreter] (pool-1-thread-1) ISPN019003: Interpreter error: java.lang.NumberFormatException: For input string: "1000l"
> at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.7.0_17]
> at java.lang.Long.parseLong(Long.java:441) [rt.jar:1.7.0_17]
> at java.lang.Long.valueOf(Long.java:540) [rt.jar:1.7.0_17]
> at org.infinispan.cli.interpreter.IspnQLParser.literal(IspnQLParser.java:3791) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at org.infinispan.cli.interpreter.IspnQLParser.putStatement(IspnQLParser.java:2147) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at org.infinispan.cli.interpreter.IspnQLParser.statement(IspnQLParser.java:689) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at org.infinispan.cli.interpreter.IspnQLParser.statements(IspnQLParser.java:237) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:157) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) [:1.7.0_17]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_17]
> at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:287) [infinispan-core-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) [rt.jar:1.7.0_17]
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792) [rt.jar:1.7.0_17]
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:498) [jboss-as-jmx-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:246) [jboss-as-jmx-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
> at org.jboss.remotingjmx.protocol.v1.ServerProxy$InvokeHandler.handle(ServerProxy.java:1034)
> at org.jboss.remotingjmx.protocol.v1.ServerProxy$MessageReciever$1.run(ServerProxy.java:215)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
--
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, 2 months
[JBoss JIRA] (ISPN-3088) Put long values from CLI, raise java.lang.NumberFormatException: For input string: "1000l" on server
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-3088?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk updated ISPN-3088:
------------------------------------
Description:
>From "help put" in CLI we get that a long is identified by a sequence of decimal digits suffixed by 'l', e.g. 1000l
But when put some data to cache e.g put num 1000l we get follow message on client side------------------------------------------------------------------
[remoting://localhost:9999/local/default]> put num 1000l
For input string: "1000l"
And exception on server side-------------------------------------------------------------------------------------------------------------------
14:17:23,179 ERROR [org.infinispan.cli.interpreter.Interpreter] (pool-1-thread-1) ISPN019003: Interpreter error: java.lang.NumberFormatException: For input string: "1000l"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.7.0_17]
at java.lang.Long.parseLong(Long.java:441) [rt.jar:1.7.0_17]
at java.lang.Long.valueOf(Long.java:540) [rt.jar:1.7.0_17]
at org.infinispan.cli.interpreter.IspnQLParser.literal(IspnQLParser.java:3791) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at org.infinispan.cli.interpreter.IspnQLParser.putStatement(IspnQLParser.java:2147) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at org.infinispan.cli.interpreter.IspnQLParser.statement(IspnQLParser.java:689) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at org.infinispan.cli.interpreter.IspnQLParser.statements(IspnQLParser.java:237) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:157) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) [:1.7.0_17]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_17]
at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_17]
at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:287) [infinispan-core-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) [rt.jar:1.7.0_17]
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792) [rt.jar:1.7.0_17]
at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:498) [jboss-as-jmx-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:246) [jboss-as-jmx-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
at org.jboss.remotingjmx.protocol.v1.ServerProxy$InvokeHandler.handle(ServerProxy.java:1034)
at org.jboss.remotingjmx.protocol.v1.ServerProxy$MessageReciever$1.run(ServerProxy.java:215)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
was:
Form help put we get that
long
a long is identified by a sequence of decimal digits suffixed by 'l', e.g. 1000l
But when put some data to cache e.g put num 1000l we get follow message on client side
[remoting://localhost:9999/local/default]> put num 1000l
For input string: "1000l"
And exception on server side
14:17:23,179 ERROR [org.infinispan.cli.interpreter.Interpreter] (pool-1-thread-1) ISPN019003: Interpreter error: java.lang.NumberFormatException: For input string: "1000l"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.7.0_17]
at java.lang.Long.parseLong(Long.java:441) [rt.jar:1.7.0_17]
at java.lang.Long.valueOf(Long.java:540) [rt.jar:1.7.0_17]
at org.infinispan.cli.interpreter.IspnQLParser.literal(IspnQLParser.java:3791) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at org.infinispan.cli.interpreter.IspnQLParser.putStatement(IspnQLParser.java:2147) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at org.infinispan.cli.interpreter.IspnQLParser.statement(IspnQLParser.java:689) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at org.infinispan.cli.interpreter.IspnQLParser.statements(IspnQLParser.java:237) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:157) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) [:1.7.0_17]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_17]
at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_17]
at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:287) [infinispan-core-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) [rt.jar:1.7.0_17]
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792) [rt.jar:1.7.0_17]
at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:498) [jboss-as-jmx-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:246) [jboss-as-jmx-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
at org.jboss.remotingjmx.protocol.v1.ServerProxy$InvokeHandler.handle(ServerProxy.java:1034)
at org.jboss.remotingjmx.protocol.v1.ServerProxy$MessageReciever$1.run(ServerProxy.java:215)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> Put long values from CLI, raise java.lang.NumberFormatException: For input string: "1000l" on server
> ----------------------------------------------------------------------------------------------------
>
> Key: ISPN-3088
> URL: https://issues.jboss.org/browse/ISPN-3088
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 5.2.4.Final
> Environment: ALL
> Reporter: Vitalii Chepeliuk
> Assignee: Tristan Tarrant
> Labels: cli
>
> From "help put" in CLI we get that a long is identified by a sequence of decimal digits suffixed by 'l', e.g. 1000l
> But when put some data to cache e.g put num 1000l we get follow message on client side------------------------------------------------------------------
> [remoting://localhost:9999/local/default]> put num 1000l
> For input string: "1000l"
> And exception on server side-------------------------------------------------------------------------------------------------------------------
> 14:17:23,179 ERROR [org.infinispan.cli.interpreter.Interpreter] (pool-1-thread-1) ISPN019003: Interpreter error: java.lang.NumberFormatException: For input string: "1000l"
> at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.7.0_17]
> at java.lang.Long.parseLong(Long.java:441) [rt.jar:1.7.0_17]
> at java.lang.Long.valueOf(Long.java:540) [rt.jar:1.7.0_17]
> at org.infinispan.cli.interpreter.IspnQLParser.literal(IspnQLParser.java:3791) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at org.infinispan.cli.interpreter.IspnQLParser.putStatement(IspnQLParser.java:2147) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at org.infinispan.cli.interpreter.IspnQLParser.statement(IspnQLParser.java:689) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at org.infinispan.cli.interpreter.IspnQLParser.statements(IspnQLParser.java:237) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:157) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) [:1.7.0_17]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_17]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_17]
> at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:287) [infinispan-core-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) [rt.jar:1.7.0_17]
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792) [rt.jar:1.7.0_17]
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:498) [jboss-as-jmx-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:246) [jboss-as-jmx-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
> at org.jboss.remotingjmx.protocol.v1.ServerProxy$InvokeHandler.handle(ServerProxy.java:1034)
> at org.jboss.remotingjmx.protocol.v1.ServerProxy$MessageReciever$1.run(ServerProxy.java:215)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
--
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, 2 months
[JBoss JIRA] (ISPN-3088) Put long values from CLI, raise java.lang.NumberFormatException: For input string: "1000l" on server
by Vitalii Chepeliuk (JIRA)
Vitalii Chepeliuk created ISPN-3088:
---------------------------------------
Summary: Put long values from CLI, raise java.lang.NumberFormatException: For input string: "1000l" on server
Key: ISPN-3088
URL: https://issues.jboss.org/browse/ISPN-3088
Project: Infinispan
Issue Type: Bug
Components: CLI
Affects Versions: 5.2.4.Final
Environment: ALL
Reporter: Vitalii Chepeliuk
Assignee: Tristan Tarrant
Form help put we get that
long
a long is identified by a sequence of decimal digits suffixed by 'l', e.g. 1000l
But when put some data to cache e.g put num 1000l we get follow message on client side
[remoting://localhost:9999/local/default]> put num 1000l
For input string: "1000l"
And exception on server side
14:17:23,179 ERROR [org.infinispan.cli.interpreter.Interpreter] (pool-1-thread-1) ISPN019003: Interpreter error: java.lang.NumberFormatException: For input string: "1000l"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.7.0_17]
at java.lang.Long.parseLong(Long.java:441) [rt.jar:1.7.0_17]
at java.lang.Long.valueOf(Long.java:540) [rt.jar:1.7.0_17]
at org.infinispan.cli.interpreter.IspnQLParser.literal(IspnQLParser.java:3791) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at org.infinispan.cli.interpreter.IspnQLParser.putStatement(IspnQLParser.java:2147) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at org.infinispan.cli.interpreter.IspnQLParser.statement(IspnQLParser.java:689) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at org.infinispan.cli.interpreter.IspnQLParser.statements(IspnQLParser.java:237) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:157) [infinispan-cli-server-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) [:1.7.0_17]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_17]
at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_17]
at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:287) [infinispan-core-5.2.4.Final-redhat-1.jar:5.2.4.Final-redhat-1]
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) [rt.jar:1.7.0_17]
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792) [rt.jar:1.7.0_17]
at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:498) [jboss-as-jmx-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:246) [jboss-as-jmx-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
at org.jboss.remotingjmx.protocol.v1.ServerProxy$InvokeHandler.handle(ServerProxy.java:1034)
at org.jboss.remotingjmx.protocol.v1.ServerProxy$MessageReciever$1.run(ServerProxy.java:215)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
--
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, 2 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 updated ISPN-3087:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=961317
> 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
>
> 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, 2 months
[JBoss JIRA] (ISPN-3087) CLI HELP of some commands should to be changed
by Vitalii Chepeliuk (JIRA)
Vitalii Chepeliuk created ISPN-3087:
---------------------------------------
Summary: 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
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, 2 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:
-----------------------------------------------
Vitalii Chepeliuk <vchepeli(a)redhat.com> made a comment on [bug 961317|https://bugzilla.redhat.com/show_bug.cgi?id=961317]
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
> 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
>
> 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, 2 months
[JBoss JIRA] (ISPN-3086) Infinite loop when creating more than two Distributed Cache nodes
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3086?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3086:
--------------------------------
Fix Version/s: 6.0.0.Final
> Infinite loop when creating more than two Distributed Cache nodes
> -----------------------------------------------------------------
>
> Key: ISPN-3086
> URL: https://issues.jboss.org/browse/ISPN-3086
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Affects Versions: 5.3.0.Beta1
> Reporter: Balazs Zsoldos
> Assignee: Galder Zamarreño
> Labels: cache, distribution
> Fix For: 6.0.0.Final
>
>
> I created a very simple application based on https://docs.jboss.org/author/display/ISPN/Using+Infinispan+as+a+JCache+p...
> I changed the code to created distributed caches instead of replicated ones. It works until two nodes but if there are three nodes it starts an infinite loop.
> *The modified XML contains:*
> <namedCache name="namedCache">
> <clustering mode="dist" />
> </namedCache>
> *The modified java code contains:*
> CacheManager cacheManager1 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
> CacheManager cacheManager2 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
> CacheManager cacheManager3 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
> *Symptom:*
> The code waits on the third command while there is an infinite loop on a background thread. I guess the benefit of distribution would come with more than two nodes but I cannot test it due to the problem above.
> Although I used infinispan via JCache I think this issue is not related to the JCache API but it comes from the infinispan core.
> *BTW:* Distributed caches seem to me about 30% slower than replicated caches concerning to put and delete functions with two nodes. I guess the
--
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, 2 months
[JBoss JIRA] (ISPN-3086) Infinite loop when creating more than two Distributed Cache nodes
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3086?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3086:
--------------------------------
Issue Type: Bug (was: Feature Request)
> Infinite loop when creating more than two Distributed Cache nodes
> -----------------------------------------------------------------
>
> Key: ISPN-3086
> URL: https://issues.jboss.org/browse/ISPN-3086
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Affects Versions: 5.3.0.Beta1
> Reporter: Balazs Zsoldos
> Assignee: Galder Zamarreño
> Labels: cache, distribution
>
> I created a very simple application based on https://docs.jboss.org/author/display/ISPN/Using+Infinispan+as+a+JCache+p...
> I changed the code to created distributed caches instead of replicated ones. It works until two nodes but if there are three nodes it starts an infinite loop.
> *The modified XML contains:*
> <namedCache name="namedCache">
> <clustering mode="dist" />
> </namedCache>
> *The modified java code contains:*
> CacheManager cacheManager1 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
> CacheManager cacheManager2 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
> CacheManager cacheManager3 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
> *Symptom:*
> The code waits on the third command while there is an infinite loop on a background thread. I guess the benefit of distribution would come with more than two nodes but I cannot test it due to the problem above.
> Although I used infinispan via JCache I think this issue is not related to the JCache API but it comes from the infinispan core.
> *BTW:* Distributed caches seem to me about 30% slower than replicated caches concerning to put and delete functions with two nodes. I guess the
--
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, 2 months
[JBoss JIRA] (ISPN-3086) Infinite loop when creating more than two Distributed Cache nodes
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3086?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3086:
--------------------------------
Assignee: Galder Zamarreño (was: Mircea Markus)
> Infinite loop when creating more than two Distributed Cache nodes
> -----------------------------------------------------------------
>
> Key: ISPN-3086
> URL: https://issues.jboss.org/browse/ISPN-3086
> Project: Infinispan
> Issue Type: Feature Request
> Components: JCache
> Affects Versions: 5.3.0.Beta1
> Reporter: Balazs Zsoldos
> Assignee: Galder Zamarreño
> Labels: cache, distribution
>
> I created a very simple application based on https://docs.jboss.org/author/display/ISPN/Using+Infinispan+as+a+JCache+p...
> I changed the code to created distributed caches instead of replicated ones. It works until two nodes but if there are three nodes it starts an infinite loop.
> *The modified XML contains:*
> <namedCache name="namedCache">
> <clustering mode="dist" />
> </namedCache>
> *The modified java code contains:*
> CacheManager cacheManager1 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
> CacheManager cacheManager2 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
> CacheManager cacheManager3 = Caching.getCacheManager(new TestClassLoader(tccl), "infinispan-jcache-cluster.xml");
> *Symptom:*
> The code waits on the third command while there is an infinite loop on a background thread. I guess the benefit of distribution would come with more than two nodes but I cannot test it due to the problem above.
> Although I used infinispan via JCache I think this issue is not related to the JCache API but it comes from the infinispan core.
> *BTW:* Distributed caches seem to me about 30% slower than replicated caches concerning to put and delete functions with two nodes. I guess the
--
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, 2 months