<jeremyevans>
headius: Just a heads up, trying 9.2.2.0 on Sequel's specs is showing failures in the threaded connection pool specs where none were failing in 9.2.0.0. Looks like Travis has the same failure on jruby-head: https://travis-ci.org/jeremyevans/sequel/jobs/452469100
<jeremyevans>
headius: not sure when this issue was introduced, let me check the Travis logs and see if I can get a better timeframe estimate
<jeremyevans>
headius: Looks like 3 days ago was the first failure of this type, and last test before that was around 7 days ago.
<jeremyevans>
headius: specs do not fail in isolation, only when grouped with other specs, and it appears to be order dependent. To reproduce in the sequel repository: jruby spec/core/connection_pool_spec.rb --seed 30056
<enebo>
jeremyevans: can you file an issue and point at that spec run?
<jeremyevans>
enebo: OK. Before that, let me do some more testing to see if this could be a Sequel issue and not a JRuby issue
<jeremyevans>
enebo: Maybe JRuby improvements has improved multithreading and I'm just now hitting failure cases that were already there
<enebo>
jeremyevans: yeah if you can narrow this down it will help but if I can bisect this I suspect it will align with us reverting to old hashing
<enebo>
jeremyevans: that is also possible I guess but if you think this was working 7 days ago then I wonder
jmalves has joined #jruby
<lopex>
enebo: lol, imagine a fallback to old hashing once bad sync is discovered
<lopex>
epic
<enebo>
lopex: we have changed some hash method and such so it is possible it is something simpler like that
<jeremyevans>
enebo: from some more analysis, it looks like not a threading issue at all, but something like ensure; foo(conn) if conn; # has foo called when conn is nil
<enebo>
oh wow...but it was passing 7 days ago?
<jeremyevans>
enebo: well, first failure was around 3 days ago on Travis with jruby-head, and commits before that were 7 days ago
jmalves has quit [Ping timeout: 260 seconds]
<enebo>
jeremyevans: ok I am bisecting and I do remember changing some branching logic but I am really surprised if that ends up being it
<enebo>
but I think I changed it a couple of months ago...I think this is the pain of us dragging out that release so long
<headius>
yo
<headius>
we need to get mixing in a few library test suites in CI
<jeremyevans>
Gotta run now, be back in about 45 minutes to continue debugging
shellac_ has joined #jruby
shellac has quit [Read error: Connection reset by peer]
shellac_ has quit [Quit: Computer has gone to sleep.]
<jeremyevans>
The underlying issue appears to be that a local variable is changing from a symbol (non-nil) to nil inside an ensure block without being reassigned
<enebo>
jeremyevans: I just think I figured this out
<enebo>
It bisected into my inlining code and I removed a method where I could not conceive of how it ever happens...I am clearly wrong
<enebo>
jeremyevans: although now that I let this run further I see another problem
<enebo>
not from the fix but just some hashing issue
<jeremyevans>
enebo: OK. Would you like more debugging info/tests from me?
shellac has joined #jruby
<enebo>
jeremyevans: actualyl we may not have an issue after all my 'co master' failed so I was still way back in history
<enebo>
jeremyevans: I am just going to quickly run your tests with master and see if I see anything but I strongly suspect we found the issue...this also solves the other bug reported today
<headius>
jeremyevans: hey, could you help us set up a CI job to run some smoke tests against Sequel?
<enebo>
jeremyevans: ALL GREEN on sequel with re-adding this method
<headius>
obviously what we have in CI is missing some failures
<headius>
I assume we just need to add some simple travis job to pull sequel and run tests
<jeremyevans>
headius: I can try. I test Sequel against jruby-head on Travis, do you think there is a way it can notify you on failure of that?
<headius>
hmm
<headius>
must be a way
<headius>
enebo: @jruby.org address we can have people point CI failure emails at maybe?
<headius>
that way they could set up travis to run against jruby-head with fail emails going to us
<enebo>
yeah that is a possibility for sure
<enebo>
I am half surprised there are not org aliases for github too
<jeremyevans>
headius: I'm not sure how to set a per-ruby-version failure notification email, hopefully the Travis documentation explains that
<enebo>
I don't know how github/travis integrate but if we can message that way it would also be nice since it has a notification system
<headius>
jeremyevans: ah yeah
<jeremyevans>
headius: I've never used Travis outside of the GitHub integration, so I'm not sure what is involved with running it directly
<headius>
well the other advantage of us having our own sequel job is that it triggers on *our* commits
<headius>
just like you want to see if sequel-head breaks on jruby-head for every commit to sequel-head, we want to see the reverse
<jeremyevans>
headius: true, that is probably better
<headius>
I suppose we can just copy your travis stuff but make it clone and build jruby
<jeremyevans>
headius: and you can target sequel releases as opposed to sequel-head, so you won't be notified if I push something that breaks on Travis
<enebo>
headius: I pushed that to master and resolved against the mysql issue. Can you maybe commit your snippet as a test in jruby regressions?
<headius>
right, that would probably be best
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
enebo: yeah I'm not sure where it would go in specs
<enebo>
yeah me neither I thought jruby:regression as it is not really behavioral
<headius>
enebo: I will add the spec and probably add a jit.threshold=0 run of jruby:regression too
<headius>
and I'll see about getting a sequel job in place