You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by "Jason Huynh (JIRA)" <ji...@apache.org> on 2016/12/12 23:15:58 UTC

[jira] [Assigned] (GEODE-2205) Race condition in startup of ConcurrentSerialGatewaySenderProcessor

     [ https://issues.apache.org/jira/browse/GEODE-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Huynh reassigned GEODE-2205:
----------------------------------

    Assignee: Jason Huynh  (was: Mark Bretl)

> Race condition in startup of ConcurrentSerialGatewaySenderProcessor
> -------------------------------------------------------------------
>
>                 Key: GEODE-2205
>                 URL: https://issues.apache.org/jira/browse/GEODE-2205
>             Project: Geode
>          Issue Type: Bug
>          Components: wan
>            Reporter: Jason Huynh
>            Assignee: Jason Huynh
>
> ConcurrentSerialGatewayEventSenderProcessor spins up the individual SerialGatewayEventSenderProcessors.  During this time, the individual processors will call waitForPrimary on the GatewaySenderAdvisor.  The advisor uses the stopped flag from ConcurrentSerialGatewayEventSenderProcessor, which starts off as false (only set to true after all Serial processors are started).  
> This is where the timing issue arises.  If the serial processors start up and the GatewaySenderAdvisor uses the flag from the Concurrent processor, the serial senders will breaks out of the loop for waitingForPrimary and then tries to handle failover.  The Concurrent processor eventually sets it's flag to true and everything continues to run.
> If the serial processor was not a primary, it stays as a secondary and is in a weird state where anything enqueued will throw an assert error.
> This issue began due to  changes in c4ae846aa1689e2c5659b6ecc17e38689dd93976 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)