Skip to content

Conversation

@bmingles
Copy link
Contributor

@bmingles bmingles commented Nov 26, 2025

DH-20578: This PR implements a RemoteFileSource plugin in Deephaven Core that can request file sources from a remote client. Key points of interest

  • RemoteFileSourceClassLoader.java - registered with the Groovy session to request remote file sources
  • RemoteFileSourceCommandResolver.java - resolves a flight command to an instance of the plugin service. This allows us to not have to register a magic variable in the session. It exports a PluginMarker object that is associated with a plugin name that the RemoteFileSourcePlugin later recognizes as an object it can suppport
  • RemoteFileSourcePlugin - the plugin
  • PluginMarker - named object used to match the flight command with the plugin. Needed since all plugins require an exported object of some sort

Related PRs

Testing

Community

  • Run Core Groovy server from this branch (I use IntelliJ debug config :web-client-api:gwtCompile server-jetty-app:run -Panonymous -Pgroovy)
  • Clone this repo https://github.com/bmingles/deephaven-groovy-remote-docs-demo and open the folder in VS Code
  • In the Deephaven view, expand the Workspace/Groovy/groovy-remote-docs-demo folder under REMOTE IMPORT SOURCES and click the + button to add test folder.
    image
  • Open docs-sample.groovy file and run against the Deephaven server. Should see testTable panel show up.

Core+

Changes are deployed to bmingles-remote-file-source vm. Can also configure VS Code to connect to https://bmingles-remote-file-source.int.illumon.com:8123/ and run same code

@github-actions
Copy link
Contributor

github-actions bot commented Nov 26, 2025

No docs changes detected for 325f688

@bmingles bmingles force-pushed the DH-20578_groovy-remote-file-sourcing branch 3 times, most recently from a48276f to fc106d6 Compare December 24, 2025 16:23
@bmingles bmingles force-pushed the DH-20578_groovy-remote-file-sourcing branch from 777b0b4 to 4d1b51c Compare January 2, 2026 17:53
implementation project(':server-jetty-11')

implementation project(':extensions-flight-sql')
implementation project(':plugin-remotefilesource')
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure if these should have been added here since I don't see any other plugins.

implementation project(':server-jetty')

implementation project(':extensions-flight-sql')
implementation project(':plugin-remotefilesource')
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure if these should have been added here since I don't see any other plugins.

@bmingles bmingles force-pushed the DH-20578_groovy-remote-file-sourcing branch from 3d7a03e to f0ced57 Compare January 5, 2026 21:14
@bmingles bmingles force-pushed the DH-20578_groovy-remote-file-sourcing branch from f0ced57 to b70f606 Compare January 5, 2026 21:15
/**
* Utility methods for working with protobuf messages in the client-side JavaScript environment.
*/
public class JsProtobufUtils {
Copy link
Member

Choose a reason for hiding this comment

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

...how sure are we that we actually need any/all of this? doesnt the generated message types give us this for free?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought we needed it in order to support the Any wrapper?

@JsType(namespace = "dh.remotefilesource", name = "RemoteFileSourceService")
public class JsRemoteFileSourceService extends HasEventHandling {
/** Event name for generic messages from the server */
@JsProperty(namespace = "dh.remotefilesource.RemoteFileSourceService")
Copy link
Member

Choose a reason for hiding this comment

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

this annotation shouldnt be necessary, should get it from the type's namespace+name, ditto below

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I got warnings for the @link #EVENT_MESSAGE in the header comment. Claude suggested this fix which worked. Is there a better way?

"RemoteFileSourcePluginFetchRequest must contain a valid result_id");
}

final String pluginName = request.getPluginName();
Copy link
Member

Choose a reason for hiding this comment

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

it appears that DeephavenRemoteFileSourcePlugin is always the pluginName set by the client, so we end up with exactly one PluginMarker. Do we anticipate more of these, or specific clients who can control this? Nothing seems able to clear old instances, do we want a mechanism (liveness?) for that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I anticipate that the Python version of the plugin may make use of this at some point.

Clearing instances is probably a good idea. Any suggestions on best way to do that?

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.

2 participants