September 2016 - infinispan-issues

[JBoss JIRA] (ISPN-7030) Allow specifying client intelligence on the Hot Rod client

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-7030: ------------------------------------- Summary: Allow specifying client intelligence on the Hot Rod client Key: ISPN-7030 URL: https://issues.jboss.org/browse/ISPN-7030 Project: Infinispan Issue Type: Enhancement Components: Remote Protocols Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 9.0.0.Final Add a configuration option to be able to specify a different intelligence level. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6041?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-6041: ------------------------------------ Indeed [~galder.zamarreno], I only created this issue to stop logging the EOF as an "unrecoverable error". I was expecting the client listener to connect to another server and continue working after logging this, but seeing JDG-517 maybe that's not the case. > 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)

9 years, 6 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 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)

9 years, 6 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)

9 years, 6 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)

9 years, 6 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)

9 years, 6 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)

9 years, 6 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)

9 years, 6 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)

9 years, 6 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)

9 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2016