Skip to content

Conversation

cesnietor
Copy link
Collaborator

@cesnietor cesnietor commented Apr 28, 2020

Trace Api uses websocket to send trace information, a
valid jwt token needs to be sent either on the header
or as a cookie of the ws request to start.
Three goroutines are needed to ensure communication
if read hearbeat fails all trace should stop by cancelling
the context. WaitGroups are needed to ensure all
goroutines finish gracefully.

Note: To test this a websocket client is needed.
-You can test it by doing /ws/trace
-PingWait is 15 sec.

Copy link
Contributor

@Alevsk Alevsk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reviewing 👀
.......
review completed 👍

@bexsoft
Copy link
Collaborator

bexsoft commented Apr 29, 2020

Please update your branch with the latest from master

@cesnietor
Copy link
Collaborator Author

Please update your branch with the latest from master

done


// Set number of goroutines to wait. wg.Wait()
// waitsuntil counter is zero (all are done)
wg.Add(3)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I read the PR description regarding 3 goroutines but I don't have all the context, is this need it for some type of quorum? would someone want to increase this to 5 or 7 in the future? If the answer is yes an env variable should be added for user to configure this value.

Copy link
Collaborator Author

@cesnietor cesnietor Apr 29, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll explain:

  • The goroutines are fixed for this (trace) functionality. A goroutine [1] for listen on client heartbeat is needed. Second goroutine is needed for Writing to the socket (send the trace info), and a Third one is needed for checking if it crashed on reading (on [1]), for instance, the client disconnected or the ping Deadline happend.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you could instead wait on their respective channels to close up instead of a wait group to ensure there's no deadlock due to a go routine never calling wg.Done, since each goroutine already returns a channel, I think essentially you aonly need sendTraceInfo routine to close to mark the process as finished, and you could signal the other 2 routines to close via context, elimitating the need for a wait group

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dvaldivia No, because I need any of (wsReadCheck or sendTraceInfo) to trigger a cancel context, not just sendTraceInfo. If ReadCheck fails that should cancel sendTraceInfo and viceversa. Else either the Read or the Trace would remain open. There is no deadlock since all return if context is cancelled.

@cesnietor cesnietor requested a review from Alevsk April 29, 2020 20:47
Trace Api uses websocket to send trace information, a
valid jwt token needs to be sent either on the header
or as a cookie of the ws request to start.
Three goroutines are needed to ensure communication
if read hearbeat fails all trace should stop by cancelling
the context. WaitGroups are needed to ensure all
goroutines finish gracefully.
Copy link
Collaborator

@bexsoft bexsoft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dvaldivia dvaldivia merged commit 8e9bd87 into minio:master Apr 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants