[JBoss JIRA] (ISPN-5262) StateTransfer considerably slow with sync indexing
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5262?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes edited comment on ISPN-5262 at 3/3/15 2:54 PM:
-----------------------------------------------------------------
Workaround is to use async indexing, setting {{"default.worker.execution"}} to {{"async"}}
was (Author: gustavonalle):
Workaround is to use async indexing, setting {{"default.worker.execution",}} to {{"async"}}
> StateTransfer considerably slow with sync indexing
> --------------------------------------------------
>
> Key: ISPN-5262
> URL: https://issues.jboss.org/browse/ISPN-5262
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Gustavo Fernandes
>
> The {{StateResponseCommand}} applies state sequentially, chunk by chunk.
> The sequential cache population by a single thread does not take advantage of the index backend automatic batching capabilities when subjected to multiple threads and consequentially state transfer time can become prohibitive for large number of entries.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (ISPN-5262) StateTransfer considerably slow with sync indexing
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5262?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-5262:
-----------------------------------------
Workaround is to use async indexing, setting {{"default.worker.execution",}} to {{"async"}}
> StateTransfer considerably slow with sync indexing
> --------------------------------------------------
>
> Key: ISPN-5262
> URL: https://issues.jboss.org/browse/ISPN-5262
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Gustavo Fernandes
>
> The {{StateResponseCommand}} applies state sequentially, chunk by chunk.
> The sequential cache population by a single thread does not take advantage of the index backend automatic batching capabilities when subjected to multiple threads and consequentially state transfer time can become prohibitive for large number of entries.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (ISPN-5262) StateTransfer considerably slow with sync indexing
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-5262:
---------------------------------------
Summary: StateTransfer considerably slow with sync indexing
Key: ISPN-5262
URL: https://issues.jboss.org/browse/ISPN-5262
Project: Infinispan
Issue Type: Enhancement
Reporter: Gustavo Fernandes
The {{StateResponseCommand}} applies state sequentially, chunk by chunk.
The sequential cache population by a single thread does not take advantage of the index backend automatic batching capabilities when subjected to multiple threads and consequentially state transfer time can become prohibitive for large number of entries.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (ISPN-5261) Transaction is recommited by joining node during merge
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5261?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-5261:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1198267
> Transaction is recommited by joining node during merge
> ------------------------------------------------------
>
> Key: ISPN-5261
> URL: https://issues.jboss.org/browse/ISPN-5261
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.1.1.Final
> Reporter: Matej Čimbora
> Assignee: Dan Berindei
>
> Transaction gets recommited after a node joins a cluster during merge and requests retransmission of previous messages, overwriting updates which happened till that point.
> 4 nodes - edg-perf01-04
> Scenario:
> 1. edg-perf01 begins a new transaction & updates value of K
> {code}
> 06:50:50,421 TRACE [org.infinispan.transaction.xa.TransactionXaAdapter] (DefaultStressor-7) start called on tx GlobalTransaction:<edg-perf01-19349>:3516:local
> {code}
> The latest view on edg-perf01 is
> {code}
> 06:50:35,103 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,edg-perf01-19349) ISPN000093: Received new, MERGED cluster view: MergeView::[edg-perf01-19349|5] (3) [edg-perf01-19349, edg-perf04-20753, edg-perf02-19191], 1 subgroups: [edg-perf01-19349|4] (2) [edg-perf01-19349, edg-perf02-19191]
> {code}
> 2. Prepare command is sent with nodes edg-perf02 & edg-perf04 responding successfully
> {code}
> 06:50:51,186 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (DefaultStressor-7) edg-perf01-19349 invoking PrepareCommand ... topologyId=12} to recipient list [edg-perf02-19191, edg-perf04-20753, edg-perf01-19349] ...
> {code}
> check message id & seqno
> {code}
> (06:50:51,195 TRACE [org.jgroups.protocols.TCP] (DefaultStressor-7) edg-perf01-19349: sending msg to null, src=edg-perf01-19349, headers are RequestCorrelator: id=200, type=REQ, id=17134, rsp_expected=true, exclusion_list=[edg-perf01-19349], NAKACK2: [MSG, seqno=1020], 20903: slaveIndex=0, TCP: [cluster_name=default])
> {code}
> 3. Transaction gets commited & value of K gets updated multiple times on edg-perf01 from this point on
> 4. edg-perf03 receives a new view containing all nodes
> {code}
> 06:50:53,963 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,edg-perf03-14171) ISPN000093: Received new, MERGED cluster view: MergeView::[edg-perf01-19349|6] (4) [edg-perf01-19349, edg-perf03-14171, edg-perf04-20753, edg-perf02-19191], 3 subgroups: [edg-perf03-14171|4] (2) [edg-perf03-14171, edg-perf04-20753], [edg-perf01-19349|5] (3) [edg-perf01-19349, edg-perf04-20753, edg-perf02-19191], [edg-perf01-19349|4] (2) [edg-perf01-19349, edg-perf02-19191]
> {code}
> 5. edg-perf03 apparently requests retransmission of previous messages (containing prepare from step#2) & edg-perf01 sends the response
> Request
> {code}
> 06:51:35,241 TRACE [org.jgroups.protocols.pbcast.NAKACK2] (Timer-3,edg-perf03-14171) edg-perf03-14171: sending XMIT_REQ ((79): {1015-1093}) to edg-perf01-19349
> {code}
> Response
> {code}
> 06:51:35,299 TRACE [org.jgroups.protocols.TCP] (INT-14,edg-perf03-14171) edg-perf03-14171: received [dst: edg-perf03-14171, src: edg-perf01-19349 (4 headers), size=975 bytes, flags=OOB|DONT_BUNDLE|NO_TOTAL_ORDER|INTERNAL], headers are RequestCorrelator: id=200, type=REQ, id=17134, rsp_expected=true, exclusion_list=[edg-perf01-19349], NAKACK2: [XMIT_RSP, seqno=1020], 20903: slaveIndex=0, TCP: [cluster_name=default]
> {code}
> 6. edg-perf03 prepares the old transaction & eventually commits it again
> {code}
> 06:51:35,304 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (INT-14,edg-perf03-14171) Attempting to execute command: PrepareCommand.....gtx=GlobalTransaction:<edg-perf01-19349>:3516:local, cacheName='testCache', topologyId=12} [sender=edg-perf01-19349]
> 06:51:35,304 TRACE [org.infinispan.statetransfer.StateTransferLockImpl] (INT-14,edg-perf03-14171) Checking if transaction data was received for topology 12, current topology is 14
> 06:51:35,305 TRACE [org.infinispan.transaction.TransactionTable] (remote-thread-40) Created and registered remote transaction ... tx=GlobalTransaction:<edg-perf01-19349>:3516:remote, ...
> 06:51:35,308 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (remote-thread-40) edg-perf03-14171 invoking PrepareCommand ... gtx=GlobalTransaction:<edg-perf01-19349>:3516:remote, cacheName='testCache', topologyId=15} to recipient list [edg-perf04-20753, edg-perf02-19191] ...
> {code}
> Successful commit responses
> {code}
> 06:51:36,750 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (remote-thread-44) Response(s) to CommitCommand {gtx=GlobalTransaction:<edg-perf01-19349>:3516:remote, cacheName='testCache', topologyId=15} is {edg-perf02-19191=SuccessfulResponse{responseValue=null} , edg-perf04-20753=SuccessfulResponse{responseValue=null} }
> {code}
> 7. When get(K) is invoked on edg-perf01, stale value is returned (the one from step #6, ignoring updates which have happened since step #3)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (ISPN-5261) Transaction is recommited by joining node during merge
by Matej Čimbora (JIRA)
Matej Čimbora created ISPN-5261:
-----------------------------------
Summary: Transaction is recommited by joining node during merge
Key: ISPN-5261
URL: https://issues.jboss.org/browse/ISPN-5261
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 7.1.1.Final
Reporter: Matej Čimbora
Assignee: Dan Berindei
Transaction gets recommited after a node joins a cluster during merge and requests retransmission of previous messages, overwriting updates which happened till that point.
4 nodes - edg-perf01-04
Scenario:
1. edg-perf01 begins a new transaction & updates value of K
{code}
06:50:50,421 TRACE [org.infinispan.transaction.xa.TransactionXaAdapter] (DefaultStressor-7) start called on tx GlobalTransaction:<edg-perf01-19349>:3516:local
{code}
The latest view on edg-perf01 is
{code}
06:50:35,103 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,edg-perf01-19349) ISPN000093: Received new, MERGED cluster view: MergeView::[edg-perf01-19349|5] (3) [edg-perf01-19349, edg-perf04-20753, edg-perf02-19191], 1 subgroups: [edg-perf01-19349|4] (2) [edg-perf01-19349, edg-perf02-19191]
{code}
2. Prepare command is sent with nodes edg-perf02 & edg-perf04 responding successfully
{code}
06:50:51,186 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (DefaultStressor-7) edg-perf01-19349 invoking PrepareCommand ... topologyId=12} to recipient list [edg-perf02-19191, edg-perf04-20753, edg-perf01-19349] ...
{code}
check message id & seqno
{code}
(06:50:51,195 TRACE [org.jgroups.protocols.TCP] (DefaultStressor-7) edg-perf01-19349: sending msg to null, src=edg-perf01-19349, headers are RequestCorrelator: id=200, type=REQ, id=17134, rsp_expected=true, exclusion_list=[edg-perf01-19349], NAKACK2: [MSG, seqno=1020], 20903: slaveIndex=0, TCP: [cluster_name=default])
{code}
3. Transaction gets commited & value of K gets updated multiple times on edg-perf01 from this point on
4. edg-perf03 receives a new view containing all nodes
{code}
06:50:53,963 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,edg-perf03-14171) ISPN000093: Received new, MERGED cluster view: MergeView::[edg-perf01-19349|6] (4) [edg-perf01-19349, edg-perf03-14171, edg-perf04-20753, edg-perf02-19191], 3 subgroups: [edg-perf03-14171|4] (2) [edg-perf03-14171, edg-perf04-20753], [edg-perf01-19349|5] (3) [edg-perf01-19349, edg-perf04-20753, edg-perf02-19191], [edg-perf01-19349|4] (2) [edg-perf01-19349, edg-perf02-19191]
{code}
5. edg-perf03 apparently requests retransmission of previous messages (containing prepare from step#2) & edg-perf01 sends the response
Request
{code}
06:51:35,241 TRACE [org.jgroups.protocols.pbcast.NAKACK2] (Timer-3,edg-perf03-14171) edg-perf03-14171: sending XMIT_REQ ((79): {1015-1093}) to edg-perf01-19349
{code}
Response
{code}
06:51:35,299 TRACE [org.jgroups.protocols.TCP] (INT-14,edg-perf03-14171) edg-perf03-14171: received [dst: edg-perf03-14171, src: edg-perf01-19349 (4 headers), size=975 bytes, flags=OOB|DONT_BUNDLE|NO_TOTAL_ORDER|INTERNAL], headers are RequestCorrelator: id=200, type=REQ, id=17134, rsp_expected=true, exclusion_list=[edg-perf01-19349], NAKACK2: [XMIT_RSP, seqno=1020], 20903: slaveIndex=0, TCP: [cluster_name=default]
{code}
6. edg-perf03 prepares the old transaction & eventually commits it again
{code}
06:51:35,304 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (INT-14,edg-perf03-14171) Attempting to execute command: PrepareCommand.....gtx=GlobalTransaction:<edg-perf01-19349>:3516:local, cacheName='testCache', topologyId=12} [sender=edg-perf01-19349]
06:51:35,304 TRACE [org.infinispan.statetransfer.StateTransferLockImpl] (INT-14,edg-perf03-14171) Checking if transaction data was received for topology 12, current topology is 14
06:51:35,305 TRACE [org.infinispan.transaction.TransactionTable] (remote-thread-40) Created and registered remote transaction ... tx=GlobalTransaction:<edg-perf01-19349>:3516:remote, ...
06:51:35,308 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (remote-thread-40) edg-perf03-14171 invoking PrepareCommand ... gtx=GlobalTransaction:<edg-perf01-19349>:3516:remote, cacheName='testCache', topologyId=15} to recipient list [edg-perf04-20753, edg-perf02-19191] ...
{code}
Successful commit responses
{code}
06:51:36,750 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (remote-thread-44) Response(s) to CommitCommand {gtx=GlobalTransaction:<edg-perf01-19349>:3516:remote, cacheName='testCache', topologyId=15} is {edg-perf02-19191=SuccessfulResponse{responseValue=null} , edg-perf04-20753=SuccessfulResponse{responseValue=null} }
{code}
7. When get(K) is invoked on edg-perf01, stale value is returned (the one from step #6, ignoring updates which have happened since step #3)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (ISPN-5260) Index should be rebuild during startup for cache stores shared=false
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-5260?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-5260:
---------------------------------------
Let's keep in mind that it's not possible to restore Infinispan's data state after a shutdown from a non-shared CacheStore, so I don't see why this would be useful.
Also, it's possible that the index state is being shared independently from the data it's indexing.
> Index should be rebuild during startup for cache stores shared=false
> --------------------------------------------------------------------
>
> Key: ISPN-5260
> URL: https://issues.jboss.org/browse/ISPN-5260
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Reporter: Wolf-Dieter Fink
>
> If a cache store is not marked as shared the indexing is skipped.
> As a result queries are not possible without calling massindexer
> - if a non persistent directory-provider is used (ram)
> - for the first start if a cache is stored before without any index
> - problematic if the application changed indexing
> For this is should be possible to re-build the index automatically during startup.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (ISPN-5260) Index should be rebuild during startup for cache stores shared=false
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-5260?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-5260:
----------------------------------
Component/s: Embedded Querying
(was: Core)
> Index should be rebuild during startup for cache stores shared=false
> --------------------------------------------------------------------
>
> Key: ISPN-5260
> URL: https://issues.jboss.org/browse/ISPN-5260
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Reporter: Wolf-Dieter Fink
>
> If a cache store is not marked as shared the indexing is skipped.
> As a result queries are not possible without calling massindexer
> - if a non persistent directory-provider is used (ram)
> - for the first start if a cache is stored before without any index
> - problematic if the application changed indexing
> For this is should be possible to re-build the index automatically during startup.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (ISPN-5221) Java Hotrod client, nearcache broken after a org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketTimeoutException
by Enrico Olivelli (JIRA)
[ https://issues.jboss.org/browse/ISPN-5221?page=com.atlassian.jira.plugin.... ]
Enrico Olivelli edited comment on ISPN-5221 at 3/3/15 10:39 AM:
----------------------------------------------------------------
I extracted from my client the configuration section, with the values I'm using in one DEV environment where the failure happens
{code}
org.infinispan.client.hotrod.configuration.ConfigurationBuilder clientBuilder = new org.infinispan.client.hotrod.configuration.ConfigurationBuilder().forceReturnValues(false);
int maxEntries = 10000;
clientBuilder.nearCache().mode(NearCacheMode.LAZY).maxEntries(maxEntries);
int sockettimeout= 1000*60*5;
int connecttimeout = 0;
clientBuilder
.socketTimeout(sockettimeout)
.connectionTimeout(connecttimeout);
clientBuilder
.addServer()
.host(serveraddress)
.port(11222);
clientBuilder.marshaller(new JavaSerializationMarshaller());
RemoteCacheManager remoteCacheManager = new RemoteCacheManager(clientBuilder.build());
{code}
was (Author: enrico.olivelli):
I extract from my client the configuration section, with the values I'm using in one DEV environment where the failure happens
{code}
org.infinispan.client.hotrod.configuration.ConfigurationBuilder clientBuilder = new org.infinispan.client.hotrod.configuration.ConfigurationBuilder().forceReturnValues(false);
int maxEntries = 10000;
clientBuilder.nearCache().mode(NearCacheMode.LAZY).maxEntries(maxEntries);
int sockettimeout= 1000*60*5;
int connecttimeout = 0;
clientBuilder
.socketTimeout(sockettimeout)
.connectionTimeout(connecttimeout);
clientBuilder
.addServer()
.host(serveraddress)
.port(11222);
clientBuilder.marshaller(new JavaSerializationMarshaller());
RemoteCacheManager remoteCacheManager = new RemoteCacheManager(clientBuilder.build());
{code}
> Java Hotrod client, nearcache broken after a org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketTimeoutException
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5221
> URL: https://issues.jboss.org/browse/ISPN-5221
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.1.0.Final
> Environment: Infinispan 7.1.0Final
> Reporter: Enrico Olivelli
> Assignee: Galder Zamarreño
> Fix For: 7.2.0.Final
>
>
> Using the LAZY nearcache (new in 7.1.0Final) when a java.net.SocketTimeoutException occurs against one of the given HotRod server the RemoteCache becames not usable any more
> This happens very frequently in our DEV environment, but I cannot reproduce it inside a test case
> This is the stacktrace
> {code}
> 15/02/13 14:51:39 ERROR event.ClientListenerNotifier: ISPN004043: Unrecoverable error reading event from server xxx.xxx.xxx/10.168.10.117:11222, exiting event reader thread
> org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketTimeoutException
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:184)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:282)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:126)
> at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:236)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.net.SocketTimeoutException
> at sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:211)
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:179)
> ... 8 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months
[JBoss JIRA] (ISPN-5221) Java Hotrod client, nearcache broken after a org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketTimeoutException
by Enrico Olivelli (JIRA)
[ https://issues.jboss.org/browse/ISPN-5221?page=com.atlassian.jira.plugin.... ]
Enrico Olivelli commented on ISPN-5221:
---------------------------------------
I extract from my client the configuration section, with the values I'm using in one DEV environment where the failure happens
org.infinispan.client.hotrod.configuration.ConfigurationBuilder clientBuilder = new org.infinispan.client.hotrod.configuration.ConfigurationBuilder().forceReturnValues(false);
int maxEntries = 10000;
clientBuilder.nearCache().mode(NearCacheMode.LAZY).maxEntries(maxEntries);
int sockettimeout= 1000*60*5;
int connecttimeout = 0;
clientBuilder
.socketTimeout(sockettimeout)
.connectionTimeout(connecttimeout);
clientBuilder
.addServer()
.host(serveraddress)
.port(11222);
clientBuilder.marshaller(new JavaSerializationMarshaller());
RemoteCacheManager remoteCacheManager = new RemoteCacheManager(clientBuilder.build());
> Java Hotrod client, nearcache broken after a org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketTimeoutException
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5221
> URL: https://issues.jboss.org/browse/ISPN-5221
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.1.0.Final
> Environment: Infinispan 7.1.0Final
> Reporter: Enrico Olivelli
> Assignee: Galder Zamarreño
> Fix For: 7.2.0.Final
>
>
> Using the LAZY nearcache (new in 7.1.0Final) when a java.net.SocketTimeoutException occurs against one of the given HotRod server the RemoteCache becames not usable any more
> This happens very frequently in our DEV environment, but I cannot reproduce it inside a test case
> This is the stacktrace
> {code}
> 15/02/13 14:51:39 ERROR event.ClientListenerNotifier: ISPN004043: Unrecoverable error reading event from server xxx.xxx.xxx/10.168.10.117:11222, exiting event reader thread
> org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketTimeoutException
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:184)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:282)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:126)
> at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:236)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.net.SocketTimeoutException
> at sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:211)
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:179)
> ... 8 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 2 months