pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
thedarkone2 has quit [Quit: thedarkone2]
cprice has quit [Ping timeout: 272 seconds]
cpuguy83 has quit [Ping timeout: 244 seconds]
cpuguy83 has joined #jruby
pilhuhn has quit [Quit: Leaving...]
raeoks has quit [Ping timeout: 272 seconds]
pilhuhn has joined #jruby
jensnockert has joined #jruby
jensnockert has quit [Remote host closed the connection]
claudiuinberlin has joined #jruby
jensnockert has joined #jruby
pawnbox has quit [Read error: No route to host]
pawnbox has joined #jruby
prasunanand has quit [Ping timeout: 240 seconds]
pawnbox has quit [Remote host closed the connection]
dinfueh__ has joined #jruby
dinfuehr_ has quit [Ping timeout: 248 seconds]
sandelius has joined #jruby
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
pilhuhn is now known as pil-afk
pawnbox has joined #jruby
<GitHub54>
[jruby] jsyeo opened pull request #4164: Use .equals instead of == to compare strings in findVariableName (master...patch-1) https://git.io/viHqr
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
pawnbox has quit [Remote host closed the connection]
jensnockert has quit [Remote host closed the connection]
<GitHub148>
[jruby] jsyeo closed pull request #4164: Use .equals instead of == to compare strings in findVariableName (master...patch-1) https://git.io/viHqr
jensnockert has joined #jruby
drbobbeaty has joined #jruby
pawnbox has joined #jruby
prasunanand has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
claudiuinberlin has quit [Remote host closed the connection]
pil-afk is now known as pilhuhn
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
claudiuinberlin has joined #jruby
claudiuinberlin has quit [Remote host closed the connection]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
shellac has joined #jruby
claudiuinberlin has joined #jruby
claudiuinberlin has quit [Ping timeout: 240 seconds]
claudiuinberlin has joined #jruby
claudiuinberlin has quit [Remote host closed the connection]
<olle>
enebo: You don't have to answer this. It's not even remotely JRuby code.
<enebo>
olle: this source does not match your stacktrace
<enebo>
olle: something is really odd about this
<enebo>
olle: Socket.connect is a public API and it internally is not finding a method in its impl (which is a non-private part of Java)
<enebo>
olle: almost like two versions of Java are mixed together or something
dinfueh__ has quit [Read error: Connection reset by peer]
<enebo>
olle: I should have said ServerSocketImpl.connect is the private part and its impl cannot find a method on the same class
dinfuehr_ has joined #jruby
<olle>
enebo: Is that the FrameHandlerFactory's fault then?
<enebo>
olle: I don’t see how
<olle>
enebo: My stacktrace listed a line like " # RUBY.new_connection_impl(/home/travis/build/gocardless/hutch/vendor/bundle/jruby/2.2/gems/march_hare-2.18.0-java/lib/march_hare/session.rb:505)
<olle>
"
<enebo>
olle: but this stack says it is using reflection to call a specific Java method…which is newConnection in ConnectionFactor
<enebo>
olle: that code ends up eventually calling Socket.connect() which is a public Java API
<enebo>
olle: its implementation should just work
<enebo>
olle: the backtrace in the PR looks pretty weird
<olle>
enebo: It's jruby-9.0.0.0 for arcane reasons I'm not privy to. Will bump to latest 9.1.5.0
<enebo>
olle: yeah so that ends up calling ConnectionFactor.newConnection in Java
<enebo>
olle: which appears to bounce through a few overloaded versions of newConnection and eventually call the FrameHandlerFactory.create
<olle>
enebo: Good, we're actually on the same page.
<enebo>
olle: some Java APIs have a SPI (Service Provider Interface) where you can register your own handler for something like let’s say a custom socket type
<enebo>
olle: so that would be my only thought. If rabbit MQ registers something through an SPI-ish way then perhaps this calls back into hutch or something which is assuming SocksSocketImpl has a remainingMillis in it
<enebo>
olle: or Java APIs have a bug and this code is creating something it does not properly support
<enebo>
olle: unlikely unless the SPI scenario is in play and we had some javai ntegration bug in 9.0.0.0
<enebo>
olle: It is the right thing to do in debugging htough
<olle>
enebo: java.util.ServiceConfigurationError, java.util.ServiceLoader - those are SPI things. I will hunt for them in the rabbitmq codebase
<enebo>
olle: yeah so what could be happening is we are seeing a weird error message as a TimeoutError swallowing the real source location error and the SPI is doing some call it hsould not on the SocksSockImpl
<olle>
enebo: Fruitless search performed.
<enebo>
olle: does this work on jruby 1.7.x?
<olle>
enebo: being not so lucky, the jruby-9.1.5.0 build didn't turn up this weird error. It has appeared once before, Google knew about this weird error stacktrace.
<olle>
enebo: I could add a matrix item for jruby 1.7
<enebo>
olle: well I am no concerned abotu 1.7 working just wondering if it works as a comparison
<enebo>
olle: if it works 100% of the time with upgrading then we would somehow be responsible
<olle>
enebo: I'll try re-running it a coupld times.
<enebo>
olle: I really don’t get how we could be responsible unless we called wrong newConnection
<enebo>
olle: even if we did it seems weird we would see goofiness like this unless we are bypassing security and improperly calling a protected/private version of a method
<olle>
enebo: One way to keep one's eye on it would be to keep on disallowing build failures for jruby-9.1.5.0
<enebo>
olle: my best theory would be we had a java integration bug where we had to pick and overload of newConnection and we somehow picked one we were not supposed to (e.g. it was marked private/protected) but we futz with setAccessible so we were able to call wrong version
<enebo>
olle: well someone will notice it when it stops that way
<olle>
enebo: Theory which rhymes with that earlier-this-month Bundler private-methods-being-rejiggled.
Aethenelle has quit [Quit: Aethenelle]
<enebo>
olle: yeah although I mean java protections and not ruby ones
<enebo>
olle: in java you can bypass visibility using reflection by saying setAccessible(true) on whatever you are interacting with and it generally lets you
<olle>
enebo: Right. (Hm, visibility-being-stored-on-the-method vs -on-the-slot)
<olle>
enebo: Oh, exciting.
<enebo>
olle: class Foo < JavaFoo where JavaFoo has protected method…so we bypass for cases like this so we can have this work as expected
claudiuinberlin has joined #jruby
<olle>
enebo: I seem to recall 9.0.3.0 or something being the cut-off for one of the features that had the older behavior. (This is me paraphrasing from what I recall.)
<olle>
enebo: Yours is a clear explanation.
<olle>
THanks.
<enebo>
olle: if you are really curious you can bisect and see if a JI commit points to what caused this
<enebo>
olle: I am mildly surprised it is us but I guess I came up with a plausible theory
<enebo>
olle: theories are cheap :)
<enebo>
olle: and if it works 100% of the time now it must have been us
<olle>
enebo: Warning: it did not mis-work 100% of the time on 9.0.0.0 either.
<enebo>
olle: I can even possibly explain that
<enebo>
olle: I think we had an issue where JVM did not predictably return method overloads in the same order run to run so we messed up our scoring algo for picking right method to call
<enebo>
olle: so some runs it would be in the order we expected and work and other times it would fail
<enebo>
olle: I thought that was an ancient issue though
<olle>
(9.0.0.0's ancient, right?)
<olle>
enebo: Solution to this little excursion - I put a link to this chat log in my PR, and called it done.
<enebo>
olle: ok well that probably works. we never did figure it out but if it works all the time now we must be the problem during 9.0.0.0
<olle>
enebo: I could only ever make it fall over on Travis.
<enebo>
olle: and as I said someone can probably bisect with best of n runs per bisect if they have to know :)
<olle>
Never gotten it wonky locally.
<enebo>
olle: what OS do you use locally?
<olle>
enebo: OS X
<olle>
enebo: El Capitan
<enebo>
olle: ah ok vs some linux on travis
subbu is now known as subbu|lunch
<olle>
enebo: I could install jruby-9.0.0.0 locally.
<olle>
enebo: it's quick, using rvm
<enebo>
olle: if it fails for you locally that way then perhaps it indicates a generic issue I guess
<olle>
enebo: I ran it like 5 times in a row using jruby-9.0.0.0 on OS X. No failure.
<enebo>
olle: heh which JVM?
<enebo>
olle: I notice travis is still using some Java 7 for that suite
<olle>
enebo: java version "1.8.0_92" Java(TM) SE Runtime Environment (build 1.8.0_92-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)
<olle>
enebo: Perhaps I can force a Java upgrade in my Travis build configuration?
<enebo>
olle: the less we have to contend with non-green CI stuff the better our perception
<enebo>
olle: looking into problems like this really helps us a lot
<olle>
m-a-r-k-e-t-i-n-g :jazz-hands:
cprice404 has quit [Quit: Konversation terminated!]
cprice404 has joined #jruby
akp has joined #jruby
bbrowning is now known as bbrowning_away
nirvdrum has joined #jruby
<nirvdrum>
I thought it was weird no one had spoken in days. Apparently my bouncer disconnected.
nicksieger has quit [Remote host closed the connection]
tcrawley is now known as tcrawley-away
<GitHub81>
[jruby] subbuss opened issue #4167: Create a different hierarchy of DynamicScope for use in startup interp + remove null checks in the existing hierarchy since they are redundant https://git.io/vi7v5
<GitHub152>
[jruby] subbuss closed issue #2465: Build a new pass that ensures that ruby locals / IR tmps are initialized https://git.io/adceFA