<GitHub109>
[jruby] camlow325 opened pull request #4614: Fix infinite loop in module name parsing for RubyModule.const_get_2_0 (jruby-1_7...fix-module-name-index-offset-for-const-get-2-0) https://git.io/vHvGc
olle has joined #jruby
keyhan has joined #jruby
keyhan has quit [Client Quit]
olle has quit [Read error: Connection reset by peer]
olle has joined #jruby
olle has quit [Read error: Connection reset by peer]
olle has joined #jruby
donV has joined #jruby
olle has quit [Read error: Connection reset by peer]
olle has joined #jruby
vtunka has joined #jruby
drbobbeaty has joined #jruby
vtunka has quit [Quit: Leaving]
vtunka has joined #jruby
olle has quit [Read error: Connection reset by peer]
olle has joined #jruby
olle has quit [Read error: Connection reset by peer]
vifino has quit [Ping timeout: 240 seconds]
vifino has joined #jruby
bbrowning_away is now known as bbrowning
hobodave has joined #jruby
hobodave_ has quit [Ping timeout: 272 seconds]
vtunka has quit [Quit: Leaving]
nirvdrum has quit [Ping timeout: 272 seconds]
<GitHub46>
[jruby] donv opened issue #4615: No response from rails 4.2.8 with puma in production mode JRuby 9.1.8.0+9.1.9.0 on Linux https://git.io/vHv57
vtunka has joined #jruby
<donV>
Hi all! Anybody running Rails+puma in production with JRuby 9.1.8.0 or 9.1.9.0? Ref.: https://git.io/vHv57
lance|afk is now known as lanceball
donV has quit [Ping timeout: 246 seconds]
hobodave_ has joined #jruby
hobodave has quit [Ping timeout: 246 seconds]
nirvdrum has joined #jruby
enebo has left #jruby [#jruby]
vtunka has quit [Quit: Leaving]
vtunka has joined #jruby
<nirvdrum>
enebo: I think I now have all the JNR PRs open.
<nirvdrum>
Tracking down that stat issue was quite annoying.
vtunka has quit [Quit: Leaving]
Aethenelle has joined #jruby
subbu is now known as subbu|meeting
camlow325 has joined #jruby
hobodave_ has quit [Quit: Computer has gone to sleep.]
kegster has quit [Ping timeout: 245 seconds]
kegster has joined #jruby
<Aethenelle>
nirvdrum: you run the tests for jnr-posix locally?
<Aethenelle>
the pom change borked everything
<Aethenelle>
also, isn't sparcv9 a 64bit platform?
<nirvdrum>
Bah. I did, but I've run "mvn install" on everything locally.
<nirvdrum>
It is.
<nirvdrum>
But the stat version is 3, not 1.
<Aethenelle>
yeah... that's what I figured...
<nirvdrum>
That took about a day to figure out :-/
<Aethenelle>
k
subbu|meeting is now known as subbu
<nirvdrum>
Memory wasn't being laid out correctly. I thought I was missing a field or endianness was being screwed up.
<nirvdrum>
Aethenelle: I have a jnr-constants PR, too, but you mentioned you haven't looked at jnr-constants so I left you off that one.
<Aethenelle>
src/main/java/jnr/constants/Platform.java seems like a breaking change
<nirvdrum>
I've noted in the commit comment and the PR explanation why I don't think it's a problem.
<nirvdrum>
But if you disagree with the reasoning, I'm happy to look into other options.
<nirvdrum>
Alternatively, I could just keep it the way it was and accept that jnr-ffi and jnr-constants will build up their package names differently.
<Aethenelle>
ahh... that's what I get for not reading...
<Aethenelle>
no outside references to getArchPackageName and none on duckduckgo either...
<nirvdrum>
It's a calculated risk.
kegster has quit [Read error: Connection reset by peer]
<nirvdrum>
Another option is to just add both options to the search list, but that looked a bit ugly.
<Aethenelle>
google agrees w/ github... I think we're in the clear.. approved but left for headius to merge
<Aethenelle>
and bing is just being silly...
<nirvdrum>
Heh.
hobodave has joined #jruby
hobodave has quit [Client Quit]
hobodave has joined #jruby
<hobodave>
thanks for getting 9.1.9.0 out headius !
Aethenelle has quit [Ping timeout: 260 seconds]
<hobodave>
Has anyone heard of any bugs in JRuby in which, under highly concurrent load, a class method call is somehow received by the wrong (specifically an anonymous Class) class?
<hobodave>
I've been troubleshooting a bug in Rails 5/ JRuby that I can't quite grok. I've spent a few weeks on this off and on, and I can't quite see how it could be a Rails bug
Aethenelle has joined #jruby
<hobodave>
I can't reproduce it in MRI, but I know that doesn't mean anything
<hobodave>
the GIL masks a lot
<Aethenelle>
hobodave: those calls dynamic or stativally defined?
<hobodave>
they are statically defined
<Aethenelle>
can you give any more detail about the anonymous class
<hobodave>
not much, it's unexpected, here's my test case
<hobodave>
Note that self.default_scope_override.nil? is called just a few lines above on #107
<hobodave>
that call _never_ raises
<Aethenelle>
this code is more voodoo than you're thinking...
<Aethenelle>
on the plus side, from what I remember of the JRuby code this would run through, it's only a JRuby bug
subbu is now known as subbu|lunch
<Aethenelle>
... for some version of "on the plus side"
<hobodave>
Aethenelle oh, trust me, I'm well aware of the voodoo at play here
<hobodave>
at the end of the day though when I run that test case in a rails console
<Aethenelle>
i think it's lines 6-13 that you're running afoul of
<hobodave>
the class loading has already occurred
<hobodave>
and the voodoo is setup already
<Aethenelle>
by you i mean your concurrency
<hobodave>
yep, I dug through all of that
<hobodave>
this is with eager_load true and cache_classes true
<Aethenelle>
those are rails options, right?
<hobodave>
yes
<hobodave>
I put "puts" statements throughout the Rails code, inside that included block, inside the "class_attribute" method
<hobodave>
I confirmed that when I boot the rails console, they setup everything
<hobodave>
and during the execution of my test, none of those things are called
<Aethenelle>
wait...
<Aethenelle>
you mean default_scope_override is only called when the console launches, not during the concurrent operations?
<hobodave>
I really didn't want this to be a JRuby bug, I'm not one to lighly point fingers at something fundamental like that
<hobodave>
hell, I'm still not convinced
<hobodave>
no
<hobodave>
I meant lines 6-13
<hobodave>
and the methods therein
<hobodave>
I even added a dbug line below 108 printing: self, the value of default_scope_override, and the owner of the :default_scope method
<hobodave>
every time it's what I expect, self is ClientNodeDetail, value is false, owner is ActiveRecord::Scoping::Default::ClassMethods
<hobodave>
somehow, by line 111, one or more threads lose track of "self"
<Aethenelle>
neither am I... but I spent a good chunk of time leading up to 9k wading through the class/inheritance handling code to implement prepend ... I'm sure some things have changed since then but I'm pretty sure that's where the issue lies
<Aethenelle>
you tried one of he other threading models? (those still around?)
<hobodave>
not aware of those
<hobodave>
what stinks is I don't know Java
<hobodave>
especially not well enough to get my hands dirty trying to figure out wtf is happening
<Aethenelle>
you'd do better than you think... a bit of a steep learning curve to pick it up this way but you'd get a rock solid foundation...
<hobodave>
what sucks is I can't even find that Class in the ObjectSpace
<hobodave>
its gone by the time the execution finishes
<Aethenelle>
try killing line 22 in your PoC
<Aethenelle>
or add some exception handling...
<hobodave>
why kill 22?
<Aethenelle>
join cleans up the threads... leave them handing around and the clas may still be there when you get to inspecting it...
<hobodave>
never thought of that
<Aethenelle>
the other thing to do will be running it from a debugger on the java side... though, that's a pain and might mess with the concurrency.
<Aethenelle>
wait... what's the result on line 108 when you hit this?
<Aethenelle>
I'm guessing it's nil
<hobodave>
interesting Aethenelle
<hobodave>
the exception message changed
<Aethenelle>
not sure how !Base.is_a?(method(:default_scope).owner) returns nil though...
<hobodave>
This is what my debug line prints: SELF: Node, default_scope_override: false, owner: ActiveRecord::Scoping::Default::ClassMethods
<hobodave>
I'm curious what happens if I call Node.connection first, before threading out
<hobodave>
testing
<Aethenelle>
same exception just a different line...
<hobodave>
oh interesting
<hobodave>
that's in my debug line
<hobodave>
hmmm
<hobodave>
let me undo my edits to the file
<Aethenelle>
iirc, you should be initializing the connection at the start of the thread...
<Aethenelle>
... or checking out a new one...
<hobodave>
it happens implicitly via the pool
<hobodave>
could be wrong, but yes I'll test that next
<Aethenelle>
I don't see anything in your code that does that... I know theres often a problem in resque workers along this line that requires explicitly checking out the connection at the start of work.
<Aethenelle>
unfortunately, I can't spend any more time on this right now...
<hobodave>
no problem, thanks Aethenelle
<Aethenelle>
np... happy hunting
<GitHub58>
[jruby] enebo pushed 1 new commit to bytelist_through_parser: https://git.io/vHfQM
<GitHub58>
jruby/bytelist_through_parser 9a0c53e Thomas E. Enebo: Merge with master
Aethenelle has quit [Ping timeout: 240 seconds]
Aethenelle has joined #jruby
Aethenelle has quit [Ping timeout: 246 seconds]
Aethenelle has joined #jruby
subbu|lunch is now known as subbu
Aethenelle has quit [Ping timeout: 240 seconds]
Aethenelle has joined #jruby
hobodave_ has joined #jruby
hobodave has quit [Ping timeout: 240 seconds]
donV has joined #jruby
Specialist has joined #jruby
<donV>
Hi all!
bbrowning is now known as bbrowning_away
hobodave_ has quit [Quit: Computer has gone to sleep.]