September 2016 - infinispan-issues

[JBoss JIRA] (ISPN-6041) Remote Listeners: Client event reader thread reports EOF as error

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-6041?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-6041: ---------------------------------------- This error appears normally when the server crashes or shuts down, but it shouldn't affect the logic on the client side because a server crashing or shutting down results in a view change, which in turn results in the client doing a client listener failover to a separate node. I believe the logging might be noisy but that's about it. [~dan.berindei], did you have any other thoughts on this? > Remote Listeners: Client event reader thread reports EOF as error > ----------------------------------------------------------------- > > Key: ISPN-6041 > URL: https://issues.jboss.org/browse/ISPN-6041 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Priority: Minor > Fix For: 9.0.0.Beta1 > > > {noformat} > 14:02:14,904 ERROR (Client-Listener-87aa07aee56d43e1) [ClientListenerNotifier] ISPN004043: Unrecoverable error reading event from server /127.0.0.1:15530, exiting event reader thread > org.infinispan.client.hotrod.exceptions.TransportException: End of stream reached! > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:198) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:305) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:147) > at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:252) > 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) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6041) Remote Listeners: Client event reader thread reports EOF as error

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-6041?page=com.atlassian.jira.plugin.... ] Galder Zamarreño edited comment on ISPN-6041 at 9/21/16 7:20 AM: ----------------------------------------------------------------- This error appears normally when the server crashes or shuts down, but it shouldn't affect the logic on the client side because a server crashing or shutting down results in a view change, which in turn results in the client doing a client listener failover to a separate node. I believe the logging might be noisy but that's about it. [~dan.berindei], did you have any other thoughts on this? was (Author: galder.zamarreno): This error appears normally when the server crashes or shuts down, but it shouldn't affect the logic on the client side because a server crashing or shutting down results in a view change, which in turn results in the client doing a client listener failover to a separate node. I believe the logging might be noisy but that's about it. [~dan.berindei], did you have any other thoughts on this? > Remote Listeners: Client event reader thread reports EOF as error > ----------------------------------------------------------------- > > Key: ISPN-6041 > URL: https://issues.jboss.org/browse/ISPN-6041 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Priority: Minor > Fix For: 9.0.0.Beta1 > > > {noformat} > 14:02:14,904 ERROR (Client-Listener-87aa07aee56d43e1) [ClientListenerNotifier] ISPN004043: Unrecoverable error reading event from server /127.0.0.1:15530, exiting event reader thread > org.infinispan.client.hotrod.exceptions.TransportException: End of stream reached! > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:198) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:305) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:147) > at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:252) > 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) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7029) Refactor context entry handling

by Radim Vansa (JIRA)

Radim Vansa created ISPN-7029: --------------------------------- Summary: Refactor context entry handling Key: ISPN-7029 URL: https://issues.jboss.org/browse/ISPN-7029 Project: Infinispan Issue Type: Enhancement Components: Core Reporter: Radim Vansa The moment and conditions when an entry should be loaded (and wrapped) into context is unclear. This also causes that (non-clustered) listeners are firing on originator. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7029) Refactor context entry handling

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7029?page=com.atlassian.jira.plugin.... ] Radim Vansa reassigned ISPN-7029: --------------------------------- Assignee: Radim Vansa > Refactor context entry handling > ------------------------------- > > Key: ISPN-7029 > URL: https://issues.jboss.org/browse/ISPN-7029 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Radim Vansa > Assignee: Radim Vansa > > The moment and conditions when an entry should be loaded (and wrapped) into context is unclear. This also causes that (non-clustered) listeners are firing on originator. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6795) ClusteredGetResponseValidityFilter swallows exceptions

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6795?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6795: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Beta1 Resolution: Done > ClusteredGetResponseValidityFilter swallows exceptions > ------------------------------------------------------ > > Key: ISPN-6795 > URL: https://issues.jboss.org/browse/ISPN-6795 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Alpha2 > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Minor > Fix For: 9.0.0.Beta1 > > > ClusteredGetValidityFilter does not accept exceptional responses. Therefore, if there's a exception on the remote side when executing ClusteredGetCommand, it's swallowed and TimeoutException is thrown instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6795) ClusteredGetResponseValidityFilter swallows exceptions

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6795?page=com.atlassian.jira.plugin.... ] Dan Berindei reopened ISPN-6795: -------------------------------- Assignee: Radim Vansa Turns out {{master}} wasn't really behaving as I expected, and it was waiting for a valid response but then still throwing the exception from the first response. Staggered get changed that, but only when staggered gets were disabled. > ClusteredGetResponseValidityFilter swallows exceptions > ------------------------------------------------------ > > Key: ISPN-6795 > URL: https://issues.jboss.org/browse/ISPN-6795 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Alpha2 > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Minor > > ClusteredGetValidityFilter does not accept exceptional responses. Therefore, if there's a exception on the remote side when executing ClusteredGetCommand, it's swallowed and TimeoutException is thrown instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6795) ClusteredGetResponseValidityFilter swallows exceptions

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6795?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6795: ------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/4486 > ClusteredGetResponseValidityFilter swallows exceptions > ------------------------------------------------------ > > Key: ISPN-6795 > URL: https://issues.jboss.org/browse/ISPN-6795 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Alpha2 > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Minor > > ClusteredGetValidityFilter does not accept exceptional responses. Therefore, if there's a exception on the remote side when executing ClusteredGetCommand, it's swallowed and TimeoutException is thrown instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6925) Race condition in staggered gets

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6925?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6925: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Beta1 Resolution: Done > Race condition in staggered gets > -------------------------------- > > Key: ISPN-6925 > URL: https://issues.jboss.org/browse/ISPN-6925 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Alpha3, 8.2.3.Final > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Critical > Fix For: 9.0.0.Beta1 > > Attachments: server.log.node1, server.log.node2, server.log.node3 > > > There's a race condition in {{CommandAwareRpcDispatcher}}, as we do staggered gets. When the {{RspList}} is prepared, and then in {{processCallsStaggered$lambda}} the {{Rsp}} is filled in - both of them can set is as received but later see that the other response was not received yet, because there's no memory barrieri n between the {{setValue}}/{{setException}} and checking {{wasReceived}}. > The race above happens when two responses come but none of them is accepted by the filter, but there's a second one in JGroupsTransport when the first response is accepted but then comes another one. In {{JGroupsTransport.invokeRemotelyAsync}} in the lambda handling {{rspListFuture.thenApply}} we may see another thread concurrently modifying the rsps; e.g. in {{checkRsp}} you find out that the concurrently written response was received and it's not an exception according to flags, but the value will be null, so you return null while you can have valid response in the other {{Rsp}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6970) Upgrade to JGroups 4.0.0.Alpha1

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/ISPN-6970?page=com.atlassian.jira.plugin.... ] Bela Ban commented on ISPN-6970: -------------------------------- Note that I released JGroups-4.0.0.Beta1 in the meantime... :-) Notable changes over Alpha1: * New Address which contains IP address and port: https://issues.jboss.org/browse/JGRP-2080 * FD_SOCK is keep trying to create a new socket to the killed server: https://issues.jboss.org/browse/JGRP-2086 * MERGE3: merge never happens: https://issues.jboss.org/browse/JGRP-2092 * TP: one single thread pool: https://issues.jboss.org/browse/JGRP-2099 (added ForkJoinPool support) * Timer: don't submit non-blocking tasks to the thread pool: https://issues.jboss.org/browse/JGRP-2100 > Upgrade to JGroups 4.0.0.Alpha1 > ------------------------------- > > Key: ISPN-6970 > URL: https://issues.jboss.org/browse/ISPN-6970 > Project: Infinispan > Issue Type: Component Upgrade > Components: Build process, Core > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Beta1 > > > This will allow us to experiment with the changes in the JGroups 4.0 before it's set in stone. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6954) LiveRunningTest.liveRun fails

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6954?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec reassigned ISPN-6954: ----------------------------------------- Assignee: Gustavo Fernandes (was: Sebastian Łaskawiec) > LiveRunningTest.liveRun fails > ----------------------------- > > Key: ISPN-6954 > URL: https://issues.jboss.org/browse/ISPN-6954 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory > Reporter: Sebastian Łaskawiec > Assignee: Gustavo Fernandes > Priority: Critical > > http://ci.infinispan.org/project.html?buildTypeId=Infinispan_MasterHotspo... > {noformat} > org.infinispan.util.concurrent.TimeoutException: Replication timeout for infinispan-ci-slave-2-49844 > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:820) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$302(JGroupsTransport.java:645) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$62/1069761118.apply(Unknown Source) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954) > at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46) > at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > 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) > ------- Stdout: ------- > ------------------------------------------------------------------- > GMS: address=infinispan-ci-slave-2-43531, cluster=ISPN > ------------------------------------------------------------------- > ------------------------------------------------------------------- > GMS: address=infinispan-ci-slave-2-306, cluster=ISPN > ------------------------------------------------------------------- > ------------------------------------------------------------------- > GMS: address=infinispan-ci-slave-2-16763, cluster=ISPN > ------------------------------------------------------------------- > ------------------------------------------------------------------- > GMS: address=infinispan-ci-slave-2-22073, cluster=ISPN > ------------------------------------------------------------------- > ------------------------------------------------------------------- > GMS: address=infinispan-ci-slave-2-39174, cluster=ISPN > ------------------------------------------------------------------- > ------------------------------------------------------------------- > GMS: address=infinispan-ci-slave-2-6165, cluster=ISPN > ------------------------------------------------------------------- > ------------------------------------------------------------------- > GMS: address=infinispan-ci-slave-2-53391, cluster=ISPN > ------------------------------------------------------------------- > ------------------------------------------------------------------- > GMS: address=infinispan-ci-slave-2-44253, cluster=ISPN > ------------------------------------------------------------------- > ------------------------------------------------------------------- > GMS: address=infinispan-ci-slave-2-49844, cluster=ISPN > ------------------------------------------------------------------- > ------------------------------------------------------------------- > GMS: address=infinispan-ci-slave-2-17081, cluster=ISPN > ------------------------------------------------------------------- > ------- Stderr: ------- > Exception in thread "Hibernate Search: async deletion of index segments-1" org.infinispan.util.concurrent.TimeoutException: Replication timeout for infinispan-ci-slave-2-17081 > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:820) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$304(JGroupsTransport.java:660) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$74/1998174876.apply(Unknown Source) > at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) > at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954) > at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:47) > at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:16) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > 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) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2016