-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support jetty as a server for deephaven #1731
Conversation
log-factory/sources/slf4j-to-log/src/main/java/org/slf4j/impl/StaticLoggerBinder.java
Outdated
Show resolved
Hide resolved
...plane-grpc-flight/src/main/java/io/deephaven/proto/flight/util/FlightExportTicketHelper.java
Outdated
Show resolved
Hide resolved
server/test/src/main/java/io/deephaven/server/test/FlightMessageRoundTripTest.java
Outdated
Show resolved
Hide resolved
web/client-api/src/main/java/io/deephaven/web/public/table_viewport.html
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good stuff. Some commented out stuff that we should probably cleanup?
Running locally, I see that server-jetty is serving up a META-INF listing from http://localhost:10000
. Should we filter to only include ide/ and jsapi/?
I'm guessing it was this way before, but some of our "Feature Demos" in jsapi/ seem to be dependent on python? Might be good to generalize and use non-console apis? (I think this is the same as your comment on table_viewport file).
Should we auto-redirect to ide/
?
server/jetty/src/main/java/io/deephaven/server/jetty/JettyBackedGrpcServer.java
Outdated
Show resolved
Hide resolved
server/jetty/src/main/java/io/deephaven/server/jetty/JettyBackedGrpcServer.java
Outdated
Show resolved
Hide resolved
server/jetty/src/main/java/io/deephaven/server/jetty/JettyBackedGrpcServer.java
Outdated
Show resolved
Hide resolved
0fc7010
to
02db307
Compare
Fixed. |
48d4960
to
7c666ee
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll check it out locally soon and go through some QA.
// set expiry to one year in the future | ||
final Calendar calendar = Calendar.getInstance(); | ||
calendar.setTime(new Date()); | ||
calendar.add(Calendar.YEAR, 1); | ||
httpResponse.setDateHeader("Expires", calendar.getTime().getTime()); | ||
// Note: immutable tells firefox to never revalidate as data will never change | ||
httpResponse.setHeader("Cache-control", "max-age=" + YEAR_IN_SECONDS + ", public, immutable"); | ||
httpResponse.setHeader("Pragma", ""); | ||
|
||
filterChain.doFilter(request, response); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd not a web-caching expert, but does this potentially (incorrectly) prevent the browser for getting updated resources after the server has been updated?
Are etags plumbed through?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Take a look at where we plug in the CacheFilter over in JettyBackedGrpcServer - those files in the static dir are all generated with their hash as part of their name, so that without a name change, the contents are (in theory) unchanged.
These filters and their configuration are the same as in DHE - to a fault, I didn't correct the path to be /ide/...
// Always add eTags | ||
context.setInitParameter("org.eclipse.jetty.servlet.Default.etags", "true"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, here are the etags. Still interested in if we are over-caching with our cache contrrol directive.
|
||
See https://github.com/deephaven/deephaven-core/issues/1657 for more discussion | ||
|
||
1. On MacOS there is an extra patch to apply at this time, to add an extra argument to clang, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Fedora, I also needed python development headers installed. That looked something like
sudo dnf install python-devel
for me. Likely want a note about headers, and how to get them for ubuntu, fedora, maybe others?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably, but better put it #1657 if we require that, this isn't meant to be exhaustive at this time.
server/jetty/README.md
Outdated
|
||
$ cd py/jpy | ||
$ JAVA_HOME=/path/to/your/java/home # Customize this to fit your computer | ||
$ python setup.py bdist_wheel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, this is breaking for me (Fedora 35 running on python 3.10.1), so I'm not able to test locally.
src/main/c/jpy_jobj.c: In function ‘JType_InitSlots’:
src/main/c/jpy_jobj.c:714:24: error: lvalue required as left operand of assignment
714 | Py_REFCNT(typeObj) = 1;
Probably time to incorporate jpy-consortium/jpy#14?
(Not a merge blocker, but should likely try to follow up sooner rather than later.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't explicitly support any python version that we don't package at this time (and probably we should actually test the matrix of packages we ship before getting into testing cross OS, py vers, arch...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We only "package" python 3.7, right? In your example though, it looks like you are building w/ 3.9?
It would be nice to get back into more native packaging / releasing of artifacts as wheels with each release; in which case we could be very explicit about what we expect should work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We only package 3.7 yes, and it happens to work with 3.9 too as far as I can tell. pyenv
probably should be used for now to try out a different version.
c09258c
to
86b6dd3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good. We know about the follow up issues. I've done some light QA of w2w across a matrix of different server types.
The default gRPC-java server implementation is backed by Netty, which has some limitations for us, and has required us to distribute the application as a set of docker containers. This patch adds support for running the server inside of Jetty, a java servlet container, and also bundles in the static html/js/css required for the JS API and UI, as well as a websocket handler that can allow the browser to connect without full grpc support.
Fixes #1270