August 2016 - infinispan-issues - Jboss List Archives

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

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-6925?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-6925: ----------------------------------- I think this could be solved by replacing RspList by a structure like Map<Address, RspWrapper> where RspWrapper would have field {{volatile Rsp}} - the Rsp would be published then atomically, instead of non-atomic copy. > 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: Dan Berindei > > 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)

7 years, 10 months

1
0
0 / 0

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

by Radim Vansa (JIRA)

Radim Vansa created ISPN-6925: --------------------------------- Summary: 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: 8.2.3.Final, 9.0.0.Alpha3 Reporter: Radim Vansa 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)

7 years, 10 months

1
0
0 / 0

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

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-6925?page=com.atlassian.jira.plugin.... ] Radim Vansa reassigned ISPN-6925: --------------------------------- Assignee: Dan Berindei > 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: Dan Berindei > > 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)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6907) Repl/Dist cache with Transactions doesn't respect shared store semantics

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6907?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6907: -------------------------------- Fix Version/s: 9.0.0.Alpha4 > Repl/Dist cache with Transactions doesn't respect shared store semantics > ------------------------------------------------------------------------ > > Key: ISPN-6907 > URL: https://issues.jboss.org/browse/ISPN-6907 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 9.0.0.Alpha3, 8.2.3.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.0.0.Alpha4, 8.2.4.Final > > > When running a replicated or distributed cache with different transaction modes and a shared cache store, it is possible for more than one node to write the store. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6924) HotRod addressCache iterator shouldn't go remote

by William Burns (JIRA)

William Burns created ISPN-6924: ----------------------------------- Summary: HotRod addressCache iterator shouldn't go remote Key: ISPN-6924 URL: https://issues.jboss.org/browse/ISPN-6924 Project: Infinispan Issue Type: Bug Components: Distributed Execution and Map/Reduce, Server Reporter: William Burns In the forum post, the stack traces show the topology update being sent back from the server to the client. However it is using a distributed iterator. This shouldn't happen as the addressCache is a REPL cache which should own all segments and thus the iterator shouldn't go remote at all and just operate on the user thread solely. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6923) HotRod bulk commands that provide a limit need to close the iterator

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6923?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6923: -------------------------------- Forum Reference: https://developer.jboss.org/message/961020?et=watches.email.thread#961020 > HotRod bulk commands that provide a limit need to close the iterator > -------------------------------------------------------------------- > > Key: ISPN-6923 > URL: https://issues.jboss.org/browse/ISPN-6923 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.0.0.Final > Reporter: William Burns > Fix For: 9.0.0.Alpha4, 8.2.4.Final > > > When using a cache that is distributed and a hotrod bulk operation with a count the entries or keys are not fully iterated upon, which requires the iterator to be manually closed or else this will consume a thread per request until the server runs out of resources. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6923) HotRod bulk commands that provide a limit need to close the iterator

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6923?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6923: -------------------------------- Summary: HotRod bulk commands that provide a limit need to close the iterator (was: HotRod bulk commands that take a count need to close the iterator) > HotRod bulk commands that provide a limit need to close the iterator > -------------------------------------------------------------------- > > Key: ISPN-6923 > URL: https://issues.jboss.org/browse/ISPN-6923 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.0.0.Final > Reporter: William Burns > Fix For: 9.0.0.Alpha4, 8.2.4.Final > > > When using a cache that is distributed and a hotrod bulk operation with a count the entries or keys are not fully iterated upon, which requires the iterator to be manually closed or else this will consume a thread per request until the server runs out of resources. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6923) HotRod bulk commands that take a count need to close the iterator

by William Burns (JIRA)

William Burns created ISPN-6923: ----------------------------------- Summary: HotRod bulk commands that take a count need to close the iterator Key: ISPN-6923 URL: https://issues.jboss.org/browse/ISPN-6923 Project: Infinispan Issue Type: Bug Components: Server Affects Versions: 8.0.0.Final Reporter: William Burns Fix For: 9.0.0.Alpha4, 8.2.4.Final When using a cache that is distributed and a hotrod bulk operation with a count the entries or keys are not fully iterated upon, which requires the iterator to be manually closed or else this will consume a thread per request until the server runs out of resources. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4999) Introduce a Listener interface

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4999?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4999: ---------------------------------- Comment: was deleted (was: Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1214694|https://bugzilla.redhat.com/show_bug.cgi?id=1214694] from MODIFIED to ON_QA) > Introduce a Listener interface > ------------------------------ > > Key: ISPN-4999 > URL: https://issues.jboss.org/browse/ISPN-4999 > Project: Infinispan > Issue Type: Feature Request > Reporter: Jim Crossley > > The notifications API is strictly annotations-based, which is awkward for more dynamic, non-Java JVM languages. I think a Listener interface with a single method taking an Event parameter would be a far simpler approach. It wouldn't have to replace the current API, merely complement it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4999) Introduce a Listener interface

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4999?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4999: ------------------------------------------ Bugzilla References: (was: https://bugzilla.redhat.com/show_bug.cgi?id=1214694) Bugzilla Update: (was: Perform) > Introduce a Listener interface > ------------------------------ > > Key: ISPN-4999 > URL: https://issues.jboss.org/browse/ISPN-4999 > Project: Infinispan > Issue Type: Feature Request > Reporter: Jim Crossley > > The notifications API is strictly annotations-based, which is awkward for more dynamic, non-Java JVM languages. I think a Listener interface with a single method taking an Event parameter would be a far simpler approach. It wouldn't have to replace the current API, merely complement it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2016