[jira] [Work logged] (BEAM-9039) Fix Datachannel stuckness on errors
[ https://issues.apache.org/jira/browse/BEAM-9039?focusedWorklogId=364778&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-364778 ] ASF GitHub Bot logged work on BEAM-9039: Author: ASF GitHub Bot Created on: 30/Dec/19 21:50 Start Date: 30/Dec/19 21:50 Worklog Time Spent: 10m Work Description: lostluck commented on pull request #10456: [BEAM-9039] Fix race on reading channel readErr URL: https://github.com/apache/beam/pull/10456 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 364778) Time Spent: 20m (was: 10m) > Fix Datachannel stuckness on errors > --- > > Key: BEAM-9039 > URL: https://issues.apache.org/jira/browse/BEAM-9039 > Project: Beam > Issue Type: Sub-task > Components: sdk-go >Affects Versions: Not applicable >Reporter: Robert Burke >Assignee: Robert Burke >Priority: Major > Fix For: Not applicable > > Time Spent: 20m > Remaining Estimate: 0h > > Catch all task for any data channel stuckness issues, in particular if any > happen on errors. Re-open this issue if a new one is found. > The last known one I have is a race condition on DataChannel.readErr > Close off a race condition where a closing DataChannel might have new readers > created for it while it is failing, causing stuckness in the bundles. > In particular, the c.readErr must be interacted while c.mu is held. > Otherwise something like the following happens. > Given a channel C, and goroutines G1,G2. > # G1 A request for a new reader on C arrives, checks C.readErr finds it null. > # G2 An error occurs on reading. The lock is acquired, and C.readErr is set. > Readers are closed. The channel is officially closed with A.forceRecreate, > removing it from the DataManager cache. > # G1 calls A.makeReader, and creates a new reader there. > There could be an arbitrary number of G1s. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (BEAM-9039) Fix Datachannel stuckness on errors
[ https://issues.apache.org/jira/browse/BEAM-9039?focusedWorklogId=364777&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-364777 ] ASF GitHub Bot logged work on BEAM-9039: Author: ASF GitHub Bot Created on: 30/Dec/19 21:49 Start Date: 30/Dec/19 21:49 Worklog Time Spent: 10m Work Description: lostluck commented on issue #10456: [BEAM-9039] Fix race on reading channel readErr URL: https://github.com/apache/beam/pull/10456#issuecomment-569806113 Thanks! I filed one as a catch all for any further stuckness issues. It should be closed with this fix, but we can re-open if we find more. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 364777) Remaining Estimate: 0h Time Spent: 10m > Fix Datachannel stuckness on errors > --- > > Key: BEAM-9039 > URL: https://issues.apache.org/jira/browse/BEAM-9039 > Project: Beam > Issue Type: Sub-task > Components: sdk-go >Affects Versions: Not applicable >Reporter: Robert Burke >Assignee: Robert Burke >Priority: Major > Fix For: Not applicable > > Time Spent: 10m > Remaining Estimate: 0h > > Catch all task for any data channel stuckness issues, in particular if any > happen on errors. > The last known one I have is a race condition on DataChannel.readErr > Close off a race condition where a closing DataChannel might have new readers > created for it while it is failing, causing stuckness in the bundles. > In particular, the c.readErr must be interacted while c.mu is held. > Otherwise something like the following happens. > Given a channel C, and goroutines G1,G2. > # G1 A request for a new reader on C arrives, checks C.readErr finds it null. > # G2 An error occurs on reading. The lock is acquired, and C.readErr is set. > Readers are closed. The channel is officially closed with A.forceRecreate, > removing it from the DataManager cache. > # G1 calls A.makeReader, and creates a new reader there. > There could be an arbitrary number of G1s. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
