[Docker] Make schemata app run within docker again
wwerner opened this issue · 6 comments
Currently, the app hangs when serving resources, but only when run within docker. Running the jar works as expected.
Steps to reproduce
- Build the jar
mvn package(⚠️ use JDK 1.8) - Run the jar
java -jar target/vlingo-schemata-0.9.3-RC4-jar-with-dependencies.jar dev - Get the index
curl localhost:9019/app/
-> This works as expected - Stop the server
- Build the docker image:
docker build . -t vlingo/vlingo-schemata - Run the docker image:
docker run -p9019:9019 vlingo/vlingo-schemata - Get the index again
curl localhost:9019/app/
-> The request hangs
@kbastani wrote an alternative implementation for serving static resources (https://github.com/vlingo/vlingo-xoom/blob/master/vlingo-xoom-server/src/main/java/io/vlingo/xoom/resource/CachedStaticFilesResource.java) using caches instead of re-reading resources from the FS that seems not to suffer from this issue.
This works on the most recent version of Docker for Mac for the latest commit hash on the master branch. There is however a hanging issue with the content length header that is a valid issue for http://localhost:8080/app or any 301 redirects being served for rewriting a URL. I think @wwerner fixed that, so we should push that fix to master.
One thing I did differently here was to make sure I installed the latest Vlingo platform core libraries using mvn clean install on vlingo-common vlingo-actors vlingo-wire and vlingo-http with the latest commit hash on those projects.
Let's make a mental note about static resource issues in the future with vlingo http. But for now let's close this issue. Thanks!
@kbastani I walked the code multiple times last week in search of how a Content-Length header is not being created. Literally when a Response is instantiated the body is checked for content and existing headers are checked for content length and added if missing. I don't see a code path where that doesn't happen. Can you pinpoint where this bypass occurs?
@kbastani I see the Content-Length header here:
The 301 Moved Permanently does not contain content and currently doesn't set a Content-Length header:
Can you clarify which of these will be problematic when a Content-Length header is missing in the Response?
private Completes<Response> redirectToApp(String path) {
return Completes.withSuccess(
Response.of(MovedPermanently, Header.Headers.of(
ResponseHeader.of("Location", path)), ""));
}The above does not work.
private Completes<Response> redirectToApp(String path) {
return Completes.withSuccess(
Response.of(MovedPermanently, Header.Headers.of(
ResponseHeader.of("Location", path),
ResponseHeader.of(ContentLength, 0)), ""));
}The above works.
@wwerner @kbastani I have written three tests. There are two in vlingo-http that test the general feature of a response sans Content-Length header, and one in vlingo-schemata that tests the specific case of MovedPermanently. All three tests pass.
UserResource
ServerTest#testThatServerRespondsPermanentRedirectWithNoContentLengthHeader
ServerTest#testThatServerRespondsOkWithNoContentLengthHeader