<venkatkms[m]>
1. Should I just create a issue with full stack trace alone and would that be enough or some other useful context would help as well?
<venkatkms[m]>
2. Is there selective ways to bypass Indy here while still using it general so we can proceed with further testing?
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
sagax has quit [Ping timeout: 240 seconds]
RosieRoff has joined #jruby
RosieRoff has quit [Client Quit]
<headius[m]>
enebo: I'm making a change to jruby-launcher install so that it also installs the executable for bin/ruby
<headius[m]>
most scripts have bin/ruby in their shebang, if they use that form, so what we have will fail just the same on Darwin because bin/ruby is still a bash script
<headius[m]>
venkatkms: hello there!
<headius[m]>
that's an interesting one
<headius[m]>
What I will need to know is what method was being called and where... we have the where in that output (column.rb:18)
<headius[m]>
I think I can guess the problem though... might have fixed this on master
<headius[m]>
enebo: should I duplicate the binary or link it? I suppose linking would be best
<venkatkms[m]>
headius: Thank you for looking into this so quickly
<headius[m]>
do please open an issue in any case
<venkatkms[m]>
headius: we have been testing upgrade to latest jruby plan to go production with Indy if that is possible.
<venkatkms[m]>
headius: we also have one more bug but I don't have the full stack trace immediately. I will share that separately
<headius[m]>
ok
<venkatkms[m]>
Sure. will open a issue
<venkatkms[m]>
A day's worth testing did not produce anything more than these two. Hopefully it is quite solid otherwise. Just curious as to whether others running Rails in production with Indy
<headius[m]>
that's excellent
<headius[m]>
there definitely are folks running indy in production
<headius[m]>
these bugs are a big reason why it might make sense to go to always-on indy in 9.3... they don't get found until production otherwise
<venkatkms[m]>
I do plan to blog and publish these benchmarks as well
sagax has quit [Remote host closed the connection]
<headius[m]>
that will be excellent... we'd be happy to host or mirror your post at blog.jruby.org
<headius[m]>
I have also seen recent JDK have that performance gain you saw, so they're definitely moving forward with every release
<venkatkms[m]>
Makes sense. We did notice our initial warmup TPS was a little slower compared to non-indy (like 10%). But any java server should not be directed with full load for at least 30 seconds or so to settle down
<venkatkms[m]>
I meant to reply to your twitter my memory recollection
<headius[m]>
yeah the warmup curve is my main reservation at this point
<headius[m]>
but I want to modify the way we use indy to start out with "simple" indy logic and then if you keep hitting that call it optimizes it better later on
<venkatkms[m]>
I very much remember back in 2008ish how much expectation was Indy to provide boost too JRuby and other platform languages
<headius[m]>
that should allow early execution to follow the simple path and get going
<venkatkms[m]>
I remember you and Tim Bray @sun at that time put a in lot of effort to make this happen
<venkatkms[m]>
Guess at times it takes much longer to see it's full value in real world. 70% over non-indy jdk 8 and ~40% over non-indy jdk 14 vs Indy / jdk 14 is quite impressive
<headius[m]>
yeah the main problem I believe is that indy turned out to be a bit tricky for JVMs to optimize
<headius[m]>
a lot of work went into that early in Java 8 timeframe to help nashorn, and it has continued to this day because of other features and libraries using indy more
<headius[m]>
it's a complex feature to be sure
<headius[m]>
it was probably premature to use JRuby with indy until at least late in Java 8 cycle, which is maybe the biggest reason we never made it on by default
<venkatkms[m]>
Makes sense
<venkatkms[m]>
I am very happy to see it all to fruition now and Thanks you
<headius[m]>
I'm very happy it is working well for you!
<headius[m]>
I hope you and your friends and family are staying safe and healtyh
<headius[m]>
BTW, do you have any posts about how you're using vert.x? They would be interesting to show other Ruby folks
<venkatkms[m]>
All are doing ok. Thank you for asking. Trust the same at your end
sagax has joined #jruby
<venkatkms[m]>
Your tweet about bringing back something like Turbobox reminded me go back to this and publish something
<headius[m]>
👍
<headius[m]>
yeah
<venkatkms[m]>
I will do it as soon as I can
<headius[m]>
let me know if I can do anything to help
<venkatkms[m]>
As part of this other bench, we did a comparison between Jruby/puma and jruby/vertx looks like Vertx results at least 15-20 more throughput
<venkatkms[m]>
So should not be a bad stack to use
<headius[m]>
oh yeah I'd love to show that to folks!
<venkatkms[m]>
Single threaded is roughly same but concurrent ones vertx is better
<headius[m]>
though I must say I'm pleased it's only in the 10-20% range
<venkatkms[m]>
I will certainly work on sharing. I have been on and of on the Ruby side as we do less on ruby side (not by choice) is the main reason.
<venkatkms[m]>
Thank you. Let me go open that issue
<headius[m]>
that's the transform exception, fixed after 9.2.11
jeremyevans has joined #jruby
<venkatkms[m]>
Perhaps should I ask the team to check by lowering to 9.2.9 and also see if the other exception goes away? At least to be able to confirm the second exception is connected to this as well?
<headius[m]>
this was a new optimization in .11 so that's a possibility
<headius[m]>
enebo hates when I add more options but I feel like indy should be user-customizable for situations like this... I am checking to see if there's any way to turn this optimization off
<headius[m]>
doesn't appear to be
<venkatkms[m]>
Let me check if we can create a local mvn package and install out of that commit
<headius[m]>
let me check if it's on the 9.2 branch
<venkatkms[m]>
I agree. Indy is a special case where some granular flags may help for people to explore and try more in production
<headius[m]>
if it's not I could put it there at least