11:09 <fidothe> lopex: the easiest thing for us to do is what cpuguy83 does already, which is build off of the upstream OpenJDK official image. I have a setup that builds a bunch of JRuby images - a set of one or more per JVM version I need to target. It's actually super easy to do, given the template Dockerfile cpuguy83 already made (I basically just took that and ran with it).

11:10 <fidothe> You can see the Rakefile I use for that here: https://github.com/fidothe/circleci-jruby-docker/blob/master/Rakefile. It's pretty simple at its core - the more complex stuff is figuring out what combinations you need. The best entrypoint into that logic is probably https://github.com/fidothe/circleci-jruby-docker/blob/67787fc42a4c29f6cba34f8a473070e37afbfa7b/Rakefile#L80-L93

11:11 <fidothe> and the calculation of variant combinations of JVM/JRuby version here: https://github.com/fidothe/circleci-jruby-docker/blob/67787fc42a4c29f6cba34f8a473070e37afbfa7b/Rakefile#L80-L93

11:12 <fidothe> The CircleCI stuff you can ignore - I'm generating JRuby images and then generating CircleCI-adapted images from those

11:19 <fidothe> And all the push-to-docker-hub stuff can be ignored as well

11:20 <vs-de[m]> hi guys

11:22 <vs-de[m]> may i ask a question about an issue i've been experiencing with jruby+puma ? i'm using jruby quite a long time now, but never had an issue like that

11:28 <fidothe> vs-de[m]: of course!

11:29 <fidothe> tbh, I'm not very likely to be useful, but the people who are are usually around soon

12:05 <vs-de[m]> it's basically just that my jruby+rails 5.1 app doesn't respond to request, despite the app is logging everything as normal up to the "completed" line where the next step would just be sending the answer. But it doesnt. It is when i upgrade jruby to 9.2.x from 9.1.

12:10 <vs-de[m]> you know, i have a line like this: I, [2019-11-15T12:07:31.626051 #10105] INFO -- : [bfec1fce-c61d-431d-b8ac-b7e67ebbb880] Completed 200 OK in 574ms

12:10 <vs-de[m]> but there is no response(!), even using curl on localhost, it's waiting for a answer forever(/up to a client-timeout)

12:11 <vs-de[m]> so i have no clue, since i have no error

12:13 <vs-de[m]> (same with different puma version up to the newest, also different java versions, just the jruby version seem to matter on that host)

17:12 <headius[m]> Sounds like ipv6

17:12 <headius[m]> vs-de can you see what address it bound to? Try hitting it at http://[::1] maybe

19:13 <vs-de[m]> curl -v says Connected to localhost (127.0.0.1) => yes, it's listening also on ipv6 but my actual request was IPv4

19:14 <vs-de[m]> it's some days ago, i try to reproduce all the stuff now. It started when i realized that my nokogiri version had a bug with the canonicalize method

19:17 <vs-de[m]> btw, is there a quick way of figuring out which system-library nokogiri (java) is actually using?

19:24 <vs-de[m]> sry, if it doesn't make sense to anyone now, but it was a longer chain of conclusions that lead to the upgrade of some gems and jruby and even java at some point. I compared different machines, one that has no trouble at all and one had all the issues (a debian 9, java: build 1.8.0_232-8u232-b09-1~deb9u1-b09 )

19:32 <vs-de[m]> and sry to repead here: the request was absolutely received by the rails-server - i could follow it live in the log up to the "completed" statement, but nothing was sent back issuing a "waiting for response" state in the http-client - do you mean that there is a possibility that a ip4 request is answered through a ip6 response ? that would explain it, but it's hard to believe though because of how sockets are handled by the

19:32 <vs-de[m]> OS after a listen call. That would be terribly messed up somewhere on a lower level - but anyways, im not 100% sure - thx for the idea so far

19:55 <headius[m]> If the request was received then it isn't an IPv6 problem

19:56 <headius[m]> We can have a look at what the threads are doing if you hit Ctrl+\ in that terminal when it is sitting there

19:56 <headius[m]> Or use the jstack command

19:56 <headius[m]> It should be fairly obvious why it's not returning the response

20:24 <vs-de[m]> ok, tyvm, i'll check that