When launched with a file path, the viewer will now still listen for TCP connections #6951
Conversation
Wumpf
changed the title
Wumpf
changed the title
|
python wheel build is a known failure. waiting for rust lint ci to finish, then merge |
There was a problem hiding this comment.
This will break the ability to open multiple files in parallel.
Today, you can do e.g. this:
$ rerun file1.rrd # in terminal 1
$ rerun file2.rrd # in terminal 2
This will open two Rerun windows, one for each terminal.
This works fine because these two windows don't bind to any port, and so they cannot conflict with one another.
With this PR, this would now fail:
$ rerun file1.rrd # in terminal 1
$ rerun file2.rrd # in terminal 2 -- ERROR: port 9876 taken
You'd have to do this instead, which is really weird from a UX standpoint:
$ rerun file1.rrd # in terminal 1
$ rerun file2.rrd --port 9877 # in terminal 2
Automatically switching the second viewer to another port that's available isn't really a solution either: it's very impractical to have a bunch of Rerun Viewers automatically open on different random ports.
I believe the correct solution is for rerun file.rrd to redirect the data to the already listening viewer for that port, if there is one.
To force-open a new viewer, the user can use --port XXXX as before (and if that port is also already taken, then the forwarding logic applies once again).
Related:
|
(Added details) |
This make sense, I can work on it. But I can't do that till Thursdy. Here comes another question: how to detect a exist viewer and the corresponding Port? Or we can create a temp file which logs the existing viwer's status, every time launch a new instance, we check this file. |
|
I found that currentlly rerun_sdk handle multiple spawn by simplly assuming the port is running a Rerun Viewer. |
|
Yes, for now you should just assume that if a port is taken, Rerun is what's bound to it. In the future we will need to make this more robust, see: ( |
petertheprocess
force-pushed
the
fix/launch_with_file_and_tcp
branch
from
41bd4b6
to
b234106
Compare
|
Sorry for the late reaction, ....
} else if is_another_viewer_running {
re_log::info!("Another viewer is already running, streaming data to it.");
// get current active recording
use re_sdk::RecordingStream;
let static_ = true;
let Some(active_recording) = RecordingStream::get(re_sdk::StoreKind::Recording, None)
else {
anyhow::bail!("No active recording found!");
};
// map is lazy, so we need take the result by let _ = ...
let _ = args
.url_or_paths
.iter()
.map(|path| active_recording.log_file_from_path(path, None, static_));
Ok(())
} else {
...I am tring to use re_sdk's log_file_from_path to do that, but I can't get access to the recording in a running viewr. In python api, it seems like a new recording will be created if a viewr is running. But I think the best default behavior should be streamming to the active record so that we can megre 2 .rrd file or append new log to a existing one. Any idea? |
Sure that would be a nice variant, but that's not what passing files in does today either. E.g. when passing in two images to rerun cli, it creates two application ids one for each image. |
What
related issue #6952
When lauched with files
rerun xxx.rrd, the viewr doesn't listen to any port.I am using
rerun-cli 0.17.0 [rustc 1.76.0 (07dca489a 2024-02-04), LLVM 17.0.6] x86_64-unknown-linux-gnu release-0.17.0 d65ca50, built 2024-07-08T13:47:55Z.Before this PR:
No log msg shows we are hosting a SDK sever over some ports.
After this PR:
Checklist
mainbuild: rerun.io/viewernightlybuild: rerun.io/viewerCHANGELOG.mdand the migration guideTo run all checks from
main, comment on the PR with@rerun-bot full-check.