Iambchop has quit [Read error: Connection reset by peer]
den_d has quit [Read error: Connection reset by peer]
den_d has joined #jruby
Iambchop has joined #jruby
ur5us has quit [Ping timeout: 264 seconds]
_whitelogger has joined #jruby
ur5us has joined #jruby
ur5us has quit [Ping timeout: 264 seconds]
ebarrett has quit [Ping timeout: 240 seconds]
ebarrett has joined #jruby
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
den_d has quit [Read error: Connection reset by peer]
den_d has joined #jruby
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
victori has quit [Ping timeout: 265 seconds]
subbu is now known as subbu|lunch
kalenp[m] has joined #jruby
subbu|lunch is now known as subbu
ur5us has joined #jruby
ur5us_ has joined #jruby
<kalenp[m]>
Hello JRuby folks. Your friends at Looker here again 🙂. We're running into a heisenbug that we can't quite pin down and now we're off in the weeds looking at potential jruby issues. Anybody available to talk it through so we can eliminate this possibility or not?
ur5us has quit [Ping timeout: 264 seconds]
<kalenp[m]>
Basically, we're getting parse errors from the json-jruby module on what appears to be well-formed json. It only shows up intermittently in production, but once it begins it seems to affect a server until we reboot the process. We're not 100% sure, but this seems to be correlated with our upgrade from java 8 to java 11.
<kalenp[m]>
One of the long-shot theories is some sort of string encoding issue, or perhaps something threading related, but we don't have a lot to back that up. Hoping that somebody here might be able to point us at some more details to investigate along those lines.