[JBoss JIRA] (ISPN-2836) org.jgroups.TimeoutException after invoking MapCombineCommand in Map/Reduce task with 2 nodes
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2836?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2836:
-------------------------------------
I agree with [~mgencur] that 1 min for 500MB shouldn't be a matter of 60 secs, or even secs for that metter. Note that in this case though, the Mapper task (assuming distributeReducePhase=false) iterates over this 500 MB and sends (almost all) data to the command originator which then Reduces it. This is not a good usage of Map/Reduce task, as the mapper should be designed to take only a fraction of the data from remote nodes and bring it back to the originator. I'd be curious to see some figures from Pedro on where the time is actually spent.
> 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, 6 months
[JBoss JIRA] (ISPN-2990) L1ManagerImpl doesn't reliably invalidate with async caches
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2990?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2990:
-------------------------------------
thinking more about this doesn't have to do with async caches as at all, but just the way two messages are ordered:
- responses to get
- invalidation messages.
> 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, 6 months
[JBoss JIRA] (ISPN-2990) L1ManagerImpl doesn't reliably invalidate with async caches
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2990?page=com.atlassian.jira.plugin.... ]
Mircea Markus edited comment on ISPN-2990 at 6/5/13 9:07 AM:
-------------------------------------------------------------
The problem here is that with async caches there's no ordering between the invalidation message and the any get message:
1. A reads k1. This is an OOB call.
2. B processes the read message and sends back the response
3. C updates k1, at this stage B sends the invalidation message to A (OOB call)
4. A processes(ignores) the invalidation message
5. A puts the stale value sent at 2 in L1
In order for this to work we need the 2 and 3 messages to be delivered in order to A.
I'm not sure it is possible ATM with jgroups to have a message sent as OOB and a response sent in order (non-OOB). [~belaban] care to comment?
was (Author: mircea.markus):
The problem here is that with async caches there's no ordering between the invalidation message and the any get message:
1. A reads k1. This is an OOB call.
2. B processes the read message and sends back the response
3. C updates k1, at this stage B sends the invalidation message to A (OOB call)
4. A processes(ignores) the invalidation message
5. A puts the stale value sent at 2 in L1
In order for this to work we need the 2 and 4 messages to be delivered in order to A.
I'm not sure it is possible ATM with jgroups to have a message sent as OOB and a response sent in order (non-OOB). [~belaban] care to comment?
> 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, 6 months
[JBoss JIRA] (ISPN-3087) CLI HELP of some commands should to be changed
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3087?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3087:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1875
> 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, 6 months
[JBoss JIRA] (ISPN-3088) Put long values from CLI, raise java.lang.NumberFormatException: For input string: "1000l" on server
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3088?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3088:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1875
> 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, 6 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:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 961334|https://bugzilla.redhat.com/show_bug.cgi?id=961334] from NEW to ASSIGNED
> 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, 6 months
[JBoss JIRA] (ISPN-2990) L1ManagerImpl doesn't reliably invalidate with async caches
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2990?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2990:
-------------------------------------
The problem here is that with async caches there's no ordering between the invalidation message and the any get message:
1. A reads k1. This is an OOB call.
2. B processes the read message and sends back the response
3. C updates k1, at this stage B sends the invalidation message to A (OOB call)
4. A processes(ignores) the invalidation message
5. A puts the stale value sent at 2 in L1
In order for this to work we need the 2 and 4 messages to be delivered in order to A.
I'm not sure it is possible ATM with jgroups to have a message sent as OOB and a response sent in order (non-OOB). [~belaban] care to comment?
> 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, 6 months
[JBoss JIRA] (ISPN-3190) Memcached server throwing NullPointerException if the mashaller is not explicitly set
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3190?page=com.atlassian.jira.plugin.... ]
Martin Gencur commented on ISPN-3190:
-------------------------------------
In other words, it turns out that we always need to define and specify the marshaller when using whatever Memcached client. This complicates things in Infinispan Server, users would need to add a specific module with the Marshaller and enable it.
> Memcached server throwing NullPointerException if the mashaller is not explicitly set
> -------------------------------------------------------------------------------------
>
> Key: ISPN-3190
> URL: https://issues.jboss.org/browse/ISPN-3190
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 5.3.0.CR1
> Reporter: Martin Gencur
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Final
>
>
> According to the tutorial at https://docs.jboss.org/author/display/ISPN/Interoperability+between+Embed... it is not necessary to specify a special marshaller under normal circumstances. However, the Memcached server seems to require it in any case and the Memcached client's "get" operation fails because we did not set any marshaller for the compatibility mode and it remained null. Note that I'm not using SpyMemcached.
> My understanding is that even if I use SpyMemcached to retrieve the entry, it will be found and retrieved but without the marshaller I simply won't understand the returned value. But something will be returned. Is my assumption correct?
> {code}
> 2013-06-05 14:12:19,054 TRACE (MemcachedServerWorker-6) [org.infinispan.container.EntryFactoryImpl] Retrieved from container ImmortalCacheEntry{key=4, value=MetadataImmortalCacheValue {value=v1, metadata=EmbeddedMetadata{lifespan=-1, maxIdle=-1, version=ServerEntryVersion(1)}}}
> 2013-06-05 14:12:19,054 TRACE (MemcachedServerWorker-6) [org.infinispan.interceptors.CallInterceptor] Executing command: GetKeyValueCommand {key=4, flags=[OPERATION_MEMCACHED]}.
> 2013-06-05 14:12:19,054 TRACE (MemcachedServerWorker-6) [org.infinispan.commands.read.GetKeyValueCommand] Found entry ImmortalCacheEntry{key=4, value=MetadataImmortalCacheValue {value=v1, metadata=EmbeddedMetadata{lifespan=-1, maxIdle=-1, version=ServerEntryVersion(1)}}}
> 2013-06-05 14:12:19,055 ERROR (MemcachedServerWorker-6) [org.infinispan.interceptors.InvocationContextInterceptor] ISPN000136: Execution error
> java.lang.NullPointerException
> at org.infinispan.server.memcached.MemcachedTypeConverter.marshall(MemcachedTypeConverter.scala:58)
> at org.infinispan.server.memcached.MemcachedTypeConverter.unboxValue(MemcachedTypeConverter.scala:45)
> at org.infinispan.server.memcached.MemcachedTypeConverter.unboxValue(MemcachedTypeConverter.scala:37)
> at org.infinispan.interceptors.compat.TypeConverterInterceptor.visitGetKeyValueCommand(TypeConverterInterceptor.java:93)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:62)
> 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.visitGetKeyValueCommand(AbstractVisitor.java:96)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:62)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> at org.infinispan.CacheImpl.getCacheEntry(CacheImpl.java:399)
> at org.infinispan.DecoratedCache.getCacheEntry(DecoratedCache.java:514)
> at org.infinispan.server.memcached.MemcachedDecoder.get(MemcachedDecoder.scala:122)
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeKey(AbstractProtocolDecoder.scala:121)
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:75)
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:49)
> at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500)
> at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435)
> at org.infinispan.server.core.AbstractProtocolDecoder.messageReceived(AbstractProtocolDecoder.scala:385)
> at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107)
> at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312)
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88)
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
> at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
> at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> {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, 6 months