Per-session dashboard services (alternative to #673)#688
Draft
SimonHeybrock wants to merge 3 commits intomainfrom
Draft
Per-session dashboard services (alternative to #673)#688SimonHeybrock wants to merge 3 commits intomainfrom
SimonHeybrock wants to merge 3 commits intomainfrom
Conversation
Move DashboardServices creation from app initialization to per-session creation in create_layout(). This allows each browser session to have its own Kafka consumer/producer, avoiding the performance issues we experienced with Panel's threaded mode when sharing resources across multiple sessions. Changes: - DashboardBase.__init__ now only stores configuration - Added _create_session_services() to create per-session services - create_sidebar_content() and create_main_content() now receive services as a parameter instead of accessing self._services - Session cleanup registered via pn.state.on_session_destroyed() - Added --num-procs CLI argument to enable multiprocess mode - Exposed exit_stack on DashboardServices for LogProducerWidget Prompt: Help me brainstorm a bit: We are experiencing performance issues using Panel's threaded mode when we have more than a couple of sessions. We are thus considering to switch to multiple processes. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Dashboard sessions now publish heartbeats like backend workers, making them visible in the renamed "System Status" tab (previously "Backend Status"). Each session publishes a ServiceStatus with namespace="dashboard" every 2 seconds, allowing users to see all active dashboard sessions alongside backend workers. Sessions send a final "stopping" heartbeat on cleanup. Changes: - Add status_sink to DashboardResources and transports - Add session heartbeat logic to DashboardServices (UUID, started_at, rate-limited publish_heartbeat method) - Call publish_heartbeat from the periodic step callback - Rename "Backend Status" tab to "System Status" Prompt: Have a look at the latest commit, we are trialing running the dashboard in processes. It would be useful if the session would publish a heartbeat, like the backend workers do, then we should see all active sessions in the "Backend Status" tab (probably needs renaming then). Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
When a browser tab closes, Panel's on_session_destroyed callback sometimes fails to fire, leaving stale sessions with open Kafka connections. This adds a browser-side JavaScript heartbeat to detect disconnected browsers and trigger cleanup proactively. The HeartbeatWidget uses ReactiveHTML to run JavaScript that increments a counter every 5 seconds. Python checks if the counter has changed; if it stops changing for 20 seconds, the browser is considered disconnected and full session cleanup is triggered (same as on_session_destroyed would do). Prompt: Session cleanup works sometimes, but misses stale sessions sometimes. Please help me to port a solution we have in another branch - the heartbeat-widget solution with browser-side javascript. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Alternative approach to multi-session support, addressing the issues found in #673 during stress testing. This is not complete, but a basis for more exploration and discussion.
Instead of sharing Kafka consumers and adding complex session-aware layers (SessionRegistry, PlotDataService, etc.), this PR takes a simpler approach: each browser session gets its own independent Kafka consumer and service stack.
Closes #609.
Closes #672.
Approach
DashboardServicescreation moved from app initialization tocreate_layout()(called per-session)pn.state.on_session_destroyed()+ browser heartbeat detection--num-procsCLI argument for multiprocess mode (further isolation if needed)Trade-offs vs #673
Given our expected ~5 concurrent sessions and low data rates (MByte/s), the additional Kafka connections and memory are acceptable.
Known limitations
This is still brittle and a starting point for discussion:
on_session_destroyedOn top of this, we would also need to ensure that things like stored config is protected from being corrupted by multiple processes (and come up with a sync mechanism).
Changes
Core per-session architecture:
dashboard.py: Services created increate_layout(), cleanup registered viaon_session_destroyeddashboard_services.py: Added session heartbeats and browser liveness detectionreduction.py: Updated to pass services to abstract methods, added--num-procsHeartbeat mechanism:
heartbeat_widget.py: ReactiveHTML widget that increments a counter from browser JSkafka_transport.py: Added status sink for session heartbeatsTest plan
--num-procs 3for multiprocess mode🤖 Generated with Claude Code