August 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6950) Errors thrown with timestamp index in H2

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6950?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-6950: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4511 > Errors thrown with timestamp index in H2 > ---------------------------------------- > > Key: ISPN-6950 > URL: https://issues.jboss.org/browse/ISPN-6950 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 9.0.0.Alpha4 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > > This also effects droping the table index -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6950) Errors thrown with timestamp index in H2

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6950?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-6950: ------------------------------- Summary: Errors thrown with timestamp index in H2 (was: Errors thrown when creating timestamp index in H2) > Errors thrown with timestamp index in H2 > ---------------------------------------- > > Key: ISPN-6950 > URL: https://issues.jboss.org/browse/ISPN-6950 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 9.0.0.Alpha4 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > > This also effects droping the table index -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5370) Make clear() non-transactional and lock free

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5370?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5370: ----------------------------------------------- Anna Manukyan <amanukya(a)redhat.com> changed the Status of [bug 1303483|https://bugzilla.redhat.com/show_bug.cgi?id=1303483] from ON_QA to VERIFIED > Make clear() non-transactional and lock free > -------------------------------------------- > > Key: ISPN-5370 > URL: https://issues.jboss.org/browse/ISPN-5370 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.2.0.CR1, 7.2.0.Final > > > New semantic for clear: > * assumes no concurrent operation while the command is in progress > * Lock free (avoids any issues with stop-the-word or deadlocks) > * non-transactional (it does not interact with current running or others transactions) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 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 commented on ISPN-6925: ----------------------------------- [~pferraro] Yep, haven't created the 8.2 PR before I get review from Dan, but I'll do it for you. By "add verbose logging to FORK" I meant adding verbose logging to FORK code :) > 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 > 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6946) Redundand indexing during topology changes in the AffinityIndexManager

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6946?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6946: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated in master. Thanks [~gustavonalle]! > Redundand indexing during topology changes in the AffinityIndexManager > ---------------------------------------------------------------------- > > Key: ISPN-6946 > URL: https://issues.jboss.org/browse/ISPN-6946 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 9.0.0.Alpha4 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6946) Redundand indexing during topology changes in the AffinityIndexManager

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6946?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6946: -------------------------------- Fix Version/s: 9.0.0.Final > Redundand indexing during topology changes in the AffinityIndexManager > ---------------------------------------------------------------------- > > Key: ISPN-6946 > URL: https://issues.jboss.org/browse/ISPN-6946 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 9.0.0.Alpha4 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.0.0.Beta1, 9.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6950) Errors thrown when creating timestamp index in H2

by Ryan Emerson (JIRA)

Ryan Emerson created ISPN-6950: ---------------------------------- Summary: Errors thrown when creating timestamp index in H2 Key: ISPN-6950 URL: https://issues.jboss.org/browse/ISPN-6950 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 9.0.0.Alpha4 Reporter: Ryan Emerson Assignee: Ryan Emerson -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6950) Errors thrown when creating timestamp index in H2

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6950?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-6950: ------------------------------- Description: This also effects droping the table index > Errors thrown when creating timestamp index in H2 > ------------------------------------------------- > > Key: ISPN-6950 > URL: https://issues.jboss.org/browse/ISPN-6950 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 9.0.0.Alpha4 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > > This also effects droping the table index -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

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

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-6925?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on ISPN-6925: ------------------------------------ [~rvansa] Your commits do not cherry-pick cleanly into 8.2.x - so you'll need to create separate branch that integrates these commits based on 8.2.x (as well as a separate PR). That's far easier for me than to reproduce the specific conditions in a unit test. FYI, TRACE logging was configured for "org.jgroups". The reason you see no trace logs is that FORK doesn't log anything below WARN (other than during state transfer). > 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 > 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, 7 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 edited comment on ISPN-6925 at 8/16/16 12:23 PM: ------------------------------------------------------------- Hi [~pferraro], I can confirm that the messages are properly sent and received (by JGroups) but not processed by Infinispan. Regrettably, there's no further logging that would pinpoint the issue, but given the fact that the responses are successful (therefore there's no issue with copying the content) it could be only this race condition (which I doubt, since the timestamps suggest the events are not interleaved) or unknown bug. I guess you can't reproduce this in an unit test, can you? I would be also interested if you can reproduce with the fix in PR. Also, the logs don't contain any FORK logs; I am not familiar with this - could you add verbose logging to FORK, too? {noformat} node2: 2016-08-16 10:25:55,217 TRACE [org.jgroups.protocols.UDP] (default task-1) node2: sending msg to node1, src=node2, headers are RequestCorrelator: corr_id=200, type=REQ, req_id=42, rsp_expected=true, FORK: ee:web, UNICAST3: DATA, seqno=65, TP: [cluster_name=ee] node1: 2016-08-16 10:25:55,219 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (thread-15,ee,node1) About to send back response SuccessfulResponse{responseValue=ImmortalCacheValue {value=org.wildfly.clustering.web.infinispan.session.SessionCreationMetaDataEntry@669d8e2a}} for command ClusteredGetCommand{key=c-TToH8iNOx-6YCwJnHNKzxhNKEc0DenxW12ZMgo, flags=[FORCE_WRITE_LOCK]} node2: 2016-08-16 10:25:55,220 TRACE [org.jgroups.protocols.UDP] (thread-17,ee,node2) node2: received [dst: node2, src: node1 (4 headers), size=22 bytes, flags=OOB|DONT_BUNDLE|NO_TOTAL_ORDER], headers are RequestCorrelator: corr_id=200, type=RSP, req_id=42, rsp_expected=true, FORK: ee:web, UNICAST3: DATA, seqno=65, conn_id=1, TP: [cluster_name=ee] 2016-08-16 10:25:55,220 TRACE [org.jgroups.protocols.UNICAST3] (thread-17,ee,node2) node2: delivering node1#65 2016-08-16 10:25:55,225 TRACE [org.jgroups.protocols.UDP] (timeout-thread--p12-t1) node2: sending msg to node3, src=node2, headers are RequestCorrelator: corr_id=200, type=REQ, req_id=43, rsp_expected=true, FORK: ee:web, UNICAST3: DATA, seqno=22, conn_id=1, TP: [cluster_name=ee] node3: 2016-08-16 10:25:55,228 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (thread-18,ee,node3) About to send back response SuccessfulResponse{responseValue=ImmortalCacheValue {value=org.wildfly.clustering.web.infinispan.session.SessionCreationMetaDataEntry@2d3471f8}} for command ClusteredGetCommand{key=c-TToH8iNOx-6YCwJnHNKzxhNKEc0DenxW12ZMgo, flags=[FORCE_WRITE_LOCK]} node2: 2016-08-16 10:25:55,232 TRACE [org.jgroups.protocols.UDP] (thread-17,ee,node2) node2: received [dst: node2, src: node3 (4 headers), size=22 bytes, flags=OOB|DONT_BUNDLE|NO_TOTAL_ORDER], headers are RequestCorrelator: corr_id=200, type=RSP, req_id=43, rsp_expected=true, FORK: ee:web, UNICAST3: DATA, seqno=20, conn_id=1, TP: [cluster_name=ee] 2016-08-16 10:25:55,232 TRACE [org.jgroups.protocols.UNICAST3] (thread-17,ee,node2) node2: delivering node3#20 {noformat} was (Author: rvansa): Hi [~pferraro], I can confirm that the messages are properly sent and received (by JGroups) but not processed by Infinispan. Regrettably, there's no further logging that would pinpoint the issue, but given the fact that the responses are successful (therefore there's no issue with copying the content) it could be only this race condition (which I doubt, since the timestamps suggest the events are not interleaved) or unknown bug. I guess you can't reproduce this in an unit test, can you? I would be also interested if you can reproduce with the fix in PR. {noformat} node2: 2016-08-16 10:25:55,217 TRACE [org.jgroups.protocols.UDP] (default task-1) node2: sending msg to node1, src=node2, headers are RequestCorrelator: corr_id=200, type=REQ, req_id=42, rsp_expected=true, FORK: ee:web, UNICAST3: DATA, seqno=65, TP: [cluster_name=ee] node1: 2016-08-16 10:25:55,219 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (thread-15,ee,node1) About to send back response SuccessfulResponse{responseValue=ImmortalCacheValue {value=org.wildfly.clustering.web.infinispan.session.SessionCreationMetaDataEntry@669d8e2a}} for command ClusteredGetCommand{key=c-TToH8iNOx-6YCwJnHNKzxhNKEc0DenxW12ZMgo, flags=[FORCE_WRITE_LOCK]} node2: 2016-08-16 10:25:55,220 TRACE [org.jgroups.protocols.UDP] (thread-17,ee,node2) node2: received [dst: node2, src: node1 (4 headers), size=22 bytes, flags=OOB|DONT_BUNDLE|NO_TOTAL_ORDER], headers are RequestCorrelator: corr_id=200, type=RSP, req_id=42, rsp_expected=true, FORK: ee:web, UNICAST3: DATA, seqno=65, conn_id=1, TP: [cluster_name=ee] 2016-08-16 10:25:55,225 TRACE [org.jgroups.protocols.UDP] (timeout-thread--p12-t1) node2: sending msg to node3, src=node2, headers are RequestCorrelator: corr_id=200, type=REQ, req_id=43, rsp_expected=true, FORK: ee:web, UNICAST3: DATA, seqno=22, conn_id=1, TP: [cluster_name=ee] node3: 2016-08-16 10:25:55,228 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (thread-18,ee,node3) About to send back response SuccessfulResponse{responseValue=ImmortalCacheValue {value=org.wildfly.clustering.web.infinispan.session.SessionCreationMetaDataEntry@2d3471f8}} for command ClusteredGetCommand{key=c-TToH8iNOx-6YCwJnHNKzxhNKEc0DenxW12ZMgo, flags=[FORCE_WRITE_LOCK]} node2: 2016-08-16 10:25:55,232 TRACE [org.jgroups.protocols.UDP] (thread-17,ee,node2) node2: received [dst: node2, src: node3 (4 headers), size=22 bytes, flags=OOB|DONT_BUNDLE|NO_TOTAL_ORDER], headers are RequestCorrelator: corr_id=200, type=RSP, req_id=43, rsp_expected=true, FORK: ee:web, UNICAST3: DATA, seqno=20, conn_id=1, TP: [cluster_name=ee] {noformat} > 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 > 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, 7 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 August 2016