Skip to content
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

Merged
merged 33 commits into from
Dec 28, 2021

Conversation

niloc132
Copy link
Member

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

build.gradle Outdated Show resolved Hide resolved
server/build.gradle Outdated Show resolved Hide resolved
server/jetty/README.md Show resolved Hide resolved
server/jetty/src/main/resources/jetty-logging.properties Outdated Show resolved Hide resolved
server/jetty/src/main/resources/logging.properties Outdated Show resolved Hide resolved
server/src/test/app.d/02-python.py Show resolved Hide resolved
Copy link
Member

@devinrsmith devinrsmith left a 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/?

@niloc132
Copy link
Member Author

Should we auto-redirect to ide/?

Fixed.

Copy link
Member

@devinrsmith devinrsmith left a 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.

buildSrc/src/main/groovy/Classpaths.groovy Outdated Show resolved Hide resolved
buildSrc/src/main/groovy/Classpaths.groovy Outdated Show resolved Hide resolved
Comment on lines +24 to +33
// 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);
Copy link
Member

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?

Copy link
Member Author

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/...

Comment on lines +60 to +61
// Always add eTags
context.setInitParameter("org.eclipse.jetty.servlet.Default.etags", "true");
Copy link
Member

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.

server/src/test/app.d/02-python.py Show resolved Hide resolved
@niloc132 niloc132 marked this pull request as ready for review December 27, 2021 23:15
server/jetty/README.md Outdated Show resolved Hide resolved

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,
Copy link
Member

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?

Copy link
Member Author

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.


$ cd py/jpy
$ JAVA_HOME=/path/to/your/java/home # Customize this to fit your computer
$ python setup.py bdist_wheel
Copy link
Member

@devinrsmith devinrsmith Dec 27, 2021

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.)

Copy link
Member Author

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...)

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

@devinrsmith devinrsmith left a 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.

@niloc132 niloc132 merged commit e90b74c into deephaven:main Dec 28, 2021
@github-actions github-actions bot locked and limited conversation to collaborators Dec 28, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

EPIC: Evaluate Jetty as replacement for Netty
2 participants