[JBoss JIRA] (ISPN-3088) Put long values from CLI, raise java.lang.NumberFormatException: For input string: "1000l" on server
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3088?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3088:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.3.0.CR2
Resolution: Done
> 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
> Fix For: 5.3.0.CR2
>
>
> 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
[JBoss JIRA] (ISPN-3182) Compatibility mode does not work correctly in ISPN server
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3182?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3182:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Compatibility mode does not work correctly in ISPN server
> ---------------------------------------------------------
>
> Key: ISPN-3182
> URL: https://issues.jboss.org/browse/ISPN-3182
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Martin Gencur
> Assignee: Tristan Tarrant
> Priority: Critical
> Fix For: 5.3.0.Final
>
>
> ISPN version: f6d1761 - Galder Zamarreño, ISPN-3062 Push JCache TCK output to screen
> Using <compatibility enabled="true"> , storing an antry via HotRod, and reading it again via HotRod fails -> null is returned.
> If the compatibility mode is disabled, the HotRod's get() operation returns the correct value.
> The following code snippet illustrates the bug:
> {code:java}
> @Test
> public void testHotRodPutRestGetTest() throws Exception {
> final String key = "1";
> // 1. Put with Hot Rod
> RemoteCache<String, byte[]> remote = getHotRodCache();
> assertEquals(null, remote.withFlags(Flag.FORCE_RETURN_VALUE).put(key, "v1".getBytes()));
> assertArrayEquals("v1".getBytes(), remote.get(key));
> //^^^^ --------- fails here
> // 2. Get with REST
> HttpMethod get = new GetMethod(getRestUrl() + "/" + key);
> getRestClient().executeMethod(get);
> assertEquals(HttpServletResponse.SC_OK, get.getStatusCode());
> assertEquals("v1".getBytes(), get.getResponseBody());
> }
> {code}
> The tests along with the example configuration file can be found at https://github.com/mgencur/infinispan-server/tree/ISPN-3176/compatibility...
> The relevant part of TRACE log is here:
> {code}
> 14:54:57,066 TRACE [org.infinispan.util.concurrent.locks.LockManagerImpl] (HotRodServerWorker-3) Successfully acquired lock 1!
> 14:54:57,066 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (HotRodServerWorker-3) Wrapping entry '1'? true
> 14:54:57,066 TRACE [org.infinispan.container.EntryFactoryImpl] (HotRodServerWorker-3) Exists in context? null
> 14:54:57,067 TRACE [org.infinispan.container.EntryFactoryImpl] (HotRodServerWorker-3) Retrieved from container null
> 14:54:57,067 TRACE [org.infinispan.container.EntryFactoryImpl] (HotRodServerWorker-3) Creating new entry.
> 14:54:57,069 TRACE [org.infinispan.interceptors.CallInterceptor] (HotRodServerWorker-3) Executing command: PutKeyValueCommand{key=1, value=v1, flags=[OPERATION_HOTROD], putIfAbsent=false, metadata=EmbeddedMetadata{version=ServerEntryVersion(1)}, successful=true}.
> 14:54:57,070 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (HotRodServerWorker-3) About to commit entry ReadCommittedEntry(74161820){key=1, value=v1, oldValue=null, isCreated=true, isChanged=true, isRemoved=false, isValid=true}
> 14:54:57,071 TRACE [org.infinispan.container.entries.ReadCommittedEntry] (HotRodServerWorker-3) Updating entry (key=1 removed=false valid=true changed=true created=true loaded=false value=v1]
> 14:54:57,071 TRACE [org.infinispan.interceptors.EntryWrappingInterceptor] (HotRodServerWorker-3) The return value is null
> 14:54:57,072 TRACE [org.infinispan.util.concurrent.locks.LockManagerImpl] (HotRodServerWorker-3) Attempting to unlock 1
> 14:54:57,073 TRACE [org.infinispan.util.concurrent.locks.containers.ReentrantPerEntryLockContainer] (HotRodServerWorker-3) Unlocking lock instance for key 1
> 14:54:57,074 TRACE [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-3) Write response ResponseWithPrevious{version=12, messageId=3, operation=PutResponse, status=Success, previous=null}
> 14:54:57,074 TRACE [org.infinispan.server.hotrod.HotRodEncoder] (HotRodServerWorker-3) Encode msg ResponseWithPrevious{version=12, messageId=3, operation=PutResponse, status=Success, previous=null}
> 14:54:57,075 TRACE [org.infinispan.server.hotrod.Encoders$Encoder12$] (HotRodServerWorker-3) Write topology response header with no change
> 14:54:57,075 TRACE [org.infinispan.server.hotrod.HotRodEncoder] (HotRodServerWorker-3) Write buffer contents A10302000000 to channel [id: 0x6ef9bcb3, /127.0.0.1:55677 => /127.0.0.1:11222]
> 14:54:57,078 TRACE [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-3) Decode using instance @265b1dbd
> 14:54:57,078 TRACE [org.infinispan.server.hotrod.Decoder10$] (HotRodServerWorker-3) Operation code: 3 has been matched to GetRequest
> 14:54:57,079 TRACE [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-3) Decoded header HotRodHeader{op=GetRequest, version=12, messageId=4, cacheName=, flag=0, clientIntelligence=3, topologyId=-1}
> 14:54:57,079 TRACE [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-3) Decode using instance @265b1dbd
> 14:54:57,080 TRACE [org.infinispan.interceptors.InvocationContextInterceptor] (HotRodServerWorker-3) Invoked with command GetKeyValueCommand {key=[B0x033e0131..(4), flags=null} and InvocationContext [org.infinispan.context.SingleKeyNonTxInvocationContext@721c2e8a]
> 14:54:57,080 TRACE [org.infinispan.container.EntryFactoryImpl] (HotRodServerWorker-3) Exists in context? null
> 14:54:57,080 TRACE [org.infinispan.container.EntryFactoryImpl] (HotRodServerWorker-3) Retrieved from container null
> 14:54:57,080 TRACE [org.infinispan.interceptors.CallInterceptor] (HotRodServerWorker-3) Executing command: GetKeyValueCommand {key=[B0x033e0131..(4), flags=null}.
> 14:54:57,081 TRACE [org.infinispan.commands.read.GetKeyValueCommand] (HotRodServerWorker-3) Entry not found
> 14:54:57,081 TRACE [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-3) Write response GetResponse{version=12, messageId=4, operation=GetResponse, status=KeyDoesNotExist, data=null}
> 14:54:57,081 TRACE [org.infinispan.server.hotrod.HotRodEncoder] (HotRodServerWorker-3) Encode msg GetResponse{version=12, messageId=4, operation=GetResponse, status=KeyDoesNotExist, data=null}
> {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
[JBoss JIRA] (ISPN-3194) Create diagnostics dumping tool
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3194?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-3194:
---------------------------------------
For an example of this, look at the JDR tool included with EAP/Wildfly
> Create diagnostics dumping tool
> -------------------------------
>
> Key: ISPN-3194
> URL: https://issues.jboss.org/browse/ISPN-3194
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API
> Affects Versions: 5.3.0.Final
> Reporter: Manik Surtani
> Assignee: Mircea Markus
> Labels: diagnostics
> Fix For: 6.0.0.Alpha1, 6.0.0.Final
>
>
> A simple script that an end-user can run on an existing cluster, that will:
> 1. Connect to a given node via JMX
> 2. Get a list of all caches on all nodes
> 3. Run JMX calls on each cache on each node to capture diagnostic data
> 4. Serialise this data (maybe JSON?), zip it up.
> This will allow end-users to share such stats for debugging and perf tuning.
> Diagnostic data to be captured would include all JMX info on hit/miss ratio, RPC performance, transaction commit/rollback rates, config details, time budgeting info, etc.
> This tool would require that JMX statistics are enabled and running for a while before the snapshot is captured.
--
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
[JBoss JIRA] (ISPN-2990) L1ManagerImpl doesn't reliably invalidate with async caches
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-2990?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-2990:
-------------------------------------
[~mircea.markus] I wouldn't think this would occur with a synchronous cache. In that case the remove would block until the owning nodes had updated their internal state. In that case the get would return the proper value from the owning node. If you had interleaving puts from an additional node that should be okay with sync as well since they both would cause invalidations to occur for each other node, except for the bug in ISPN-2965. Unless I am missing something this one seems specific to async caches.
> L1ManagerImpl doesn't reliably invalidate with async caches
> -----------------------------------------------------------
>
> Key: ISPN-2990
> URL: https://issues.jboss.org/browse/ISPN-2990
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.1.Final
> Reporter: Sebastian Tusk
> Assignee: William Burns
> Labels: onboard
>
> B is owner of k,v1
> A has k,v1 in L1
> 1. TX: A puts k,v2
> 2. TX: A sends async PrepareCommand k,v2 to B (one-phase-commit)
> 3. TX: A removes k,v1 from L1
> 4. A putForExternalRead k,v1 and has it in L1 again
> 5. TX: B executes PrepareCommand k,v2 but doesn't send invalidation to origin
> Result: A has k,v1 and B has k,v2
> Solution: For async caches send invalidation to origin too.
> The problem is that the owner updates the cache entry asynchronously. This gives the origin of the transaction time to request the entry. Here an outdated version is received and placed in L1. The owner never invalidates the entry and as result the cache is inconsistent.
--
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
[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:
----------------------------------
Increasing the value of Sync.replTimeout, allows the job to get past the TimeoutException, but then I get OOM exceptions when using larger data files. (1GB file)
> 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