You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am adding an option to ddlog CLI to start ddshow before initializing the dataflow graph. This should greatly simplify the profiling workflow as the user only needs to type one command and doesn't need to worry about providing matching arguments (socket address, number of workers). Problem is, there is no easy way to know that ddshow is listening. Starting the graph before ddshow has called bind() returns an error. I noticed that ddshow prints a message to stdout on startup ("Waiting for 2 Timely connections on 127.0.0.1:51317..."), so I thought of to capturing its stdout and waiting for the message; however I checked the source and it does this before actually calling bind. Also, this seems like an ugly hack...
It's be great to have a more reliable startup protocol (any ideas?) or at least reorder things to print the message once ddshow is actually listening...
The text was updated successfully, but these errors were encountered:
PS. The new version of ddshow no longer prints anything on stdout, so I gave up on trying to implement a reliable status check and just wait for few hundred milliseconds in the hope that ddshow will be ready by then.
I am adding an option to ddlog CLI to start
ddshow
before initializing the dataflow graph. This should greatly simplify the profiling workflow as the user only needs to type one command and doesn't need to worry about providing matching arguments (socket address, number of workers). Problem is, there is no easy way to know that ddshow is listening. Starting the graph before ddshow has calledbind()
returns an error. I noticed thatddshow
prints a message tostdout
on startup ("Waiting for 2 Timely connections on 127.0.0.1:51317..."), so I thought of to capturing its stdout and waiting for the message; however I checked the source and it does this before actually callingbind
. Also, this seems like an ugly hack...It's be great to have a more reliable startup protocol (any ideas?) or at least reorder things to print the message once ddshow is actually listening...
The text was updated successfully, but these errors were encountered: