mengu has quit [Remote host closed the connection]
<headius> huh seems to have corrected itself when I rebased the PR
<headius> enebo: seems some spec failures after your changes?
<rdubya> headius, enebo: sorry, I was afk, that code is used on every query that gets converted to an ActiveRecord::Result object, which I believe is most of them
<rdubya> I'm pretty sure the previous version of the adapter just returned arrays of data that had already been converted, but that wasn't playing well with how they refactored types in Rails 5, iirc
<headius> rdubya: ok
<headius> thank you
travis-ci has joined #jruby
<travis-ci> jruby/jruby (ruby-2.6:a708b81 by Thomas E Enebo): The build is still failing. (https://travis-ci.org/jruby/jruby/builds/466707218)
travis-ci has left #jruby [#jruby]
Puffball has quit [Remote host closed the connection]
subbu has quit [Ping timeout: 252 seconds]
subbu has joined #jruby
jmalves has joined #jruby
travis-ci has joined #jruby
<travis-ci> kares/jruby (proper-thread-sync:b1544cf by kares): The build was broken. (https://travis-ci.org/kares/jruby/builds/466866457)
travis-ci has left #jruby [#jruby]
slyphon has quit [Read error: No route to host]
slyphon has joined #jruby
shellac has joined #jruby
drbobbeaty has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
mengu has joined #jruby
mengu has quit [Remote host closed the connection]
mengu has joined #jruby
<mengu> hi all
drbobbeaty has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
mengu has quit [Remote host closed the connection]
mengu has joined #jruby
shellac has joined #jruby
mengu has quit [Remote host closed the connection]
mengu has joined #jruby
Puffball has joined #jruby
Aethenelle has quit [Ping timeout: 268 seconds]
mengu_ has joined #jruby
mengu has quit [Ping timeout: 250 seconds]
<mengu_> headius: enebo: rdubya we've got another one: https://github.com/pgjdbc/pgjdbc/issues/1374#issuecomment-446566056
mengu has joined #jruby
mengu_ has quit [Ping timeout: 250 seconds]
<enebo> mengu: I commented on the issue
<mengu> thank you very much enebo
<enebo> mengu: yeah I am not sure if he is just asking to understand better or if he is pushing back because it is extra support for them
<mengu> enebo: we'll see
<enebo> I really don't see them dumping those two values internally
<mengu> i don't think it'd cause them no harm
<mengu> *any harm
<enebo> rdubya: ^ look at that issue and my comment to make sure we only need oid and mod. I do not see any other uses
xardion has quit [Remote host closed the connection]
<rdubya> enebo: yeah those are the only values we need at this point, iirc I was able to get all the other info I needed publicly
<enebo> rdubya: thanks for verifying...I searched our code but we can be tricky sometimes from ruby side
xardion has joined #jruby
<mengu> how's ruby guys doing it
<mengu> i did check it out but didn't get anything
<mengu> too much magic
<enebo> mengu: the native c ext works directly with oid and mod which is why ar is written passing those values around
<enebo> mengu: I think those are significant non-internal things if you write to pg directly which is why JDBC adapter is storing them as fields
<enebo> so I am pretty hopeful he will open those two values up
<enebo> I am sympathetic to opening all of field if not all those fields/methods are more than their impl details
mengu has quit [Quit: Leaving...]
rdubya has quit [Quit: Leaving.]
<lopex> headius: busy busy now, but next week will be better
<lopex> headius, enebo: will unicode 11 be a blocker for our 2.6 compat release ?
shellac has quit [Ping timeout: 240 seconds]
rdubya has joined #jruby
rdubya has quit [Quit: Leaving.]
rdubya has joined #jruby
mengu has joined #jruby
<mengu> night all
<mengu> i don't know if its AR bug or ARJDBC bug, it does not take timeout parameter in the config into account
<mengu> i'm investigating
<mengu> looks like it is actually AR
<mengu> yes
<mengu> spec.config[:checkout_timeout]
<mengu> this is nil, despite the fact that i set timeout: 60000 in database.yml
<mengu> OH, wait, it's my mistake i think
<mengu> goddammit
<mengu> i use env var for db url
<mengu> i should have put it there
<mengu> meh
<mengu> no problems :D
rdubya has quit [Quit: Leaving.]
rdubya has joined #jruby
<headius> lopex: probably not? What typically changes in these updates?
<lopex> headius: code ranges
<lopex> mostly
<headius> yeah but only on higher plane weird stuff right?
<lopex> whole ranges for unicode
<headius> I'm just trying to understand how likely it is a typical user would notice an update from unicode 10 to 11
<lopex> of course all of them are esoteris
<lopex> *esoteric
<lopex> probably not
<lopex> headius: that \X change is blocking the update
<lopex> oh well,...
<lopex> \X changed
<lopex> so some emoji wont work :P
<headius> I don't think it blocks then
<lopex> yeah, just asking
<headius> unfinished bullet for 2.6 support when we release if it's not in there
<lopex> git df
<lopex> er
<lopex> yeah, only ranges
<lopex> and no encoding changes
<mengu> channel, may i ask what objectspace is? why is it disabled?
<lopex> generation scripts stilll work ok though
<lopex> mengu: weakref pressure
<lopex> and contention
<lopex> and a lot more allocation for weakrefs
<lopex> so in turn gc pressure :P
<mengu> gotta read on then
<mengu> *that
<lopex> headius: though, since there's not a whole lot working threads in jruby apps mostly, then tlabs are not a big issue right ?
<mengu> looks like the newrelic gem has some problems then, opt/tomcat/webapps/ROOT/WEB-INF/gems/gems/newrelic_rpm-5.5.0.348/lib/new_relic/agent/transaction_time_aggregator.rb:101: warning: ObjectSpace is disabled; _id2ref only supports immediates, pass -X+O to enable
<lopex> well, threads competing for allocation
<lopex> mengu: but classes and singletons are in OS afair
<lopex> mengu: mri used to us mark/sweep so it always had those objects in hand
<lopex> *s/us/use/
<mengu> huh, they are using ObjectSpace._id2ref
<mengu> is there a jrubyish way of what they're doing?
<lopex> enable it
<lopex> that message is confusing
<lopex> it should read "Since ObjectSpace is disabled.."
<lopex> headius: ^^
<lopex> so true/false/nil/1 are immediates in mris nomenclature
<headius> mengu_: lovely
<headius> they should not be using id2ref
<headius> nobody should ever use id2ref
<lopex> that's another story
<headius> enabling objectspace will slow your app to a crawl on JRuby
<headius> why does this project have no bug tracker
<mengu> i am not going to enable objectspace, no worries
<mengu> instead i'll get rid of the newrelic rpm gem
<mengu> after switching to connection pooling and jndi
<mengu> somewhere, my app is choking
<mengu> no response from tomcat at all
<mengu> just times out
<headius> get a thread dump, we can see where it's stuck
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<mengu> ahem, if i may, how do i do that when the app runs as war on tomcat?
<mengu> kill -3
<mengu> it says :D
<lopex> yes
<mengu> alright, i'm generating one
<lopex> there will be a lot
<mengu> indeed there's a lot
<mengu> i'm pasting on pastebin
<lopex> I see either that condition variable and that agent_thread.rb:25 from newrelic
<lopex> headius: ^^
<headius> I emailed New Relic about the id2ref thing
<lopex> headius: does it even work with that new generation gc mri has ?
<headius> I'm not sure actually
<headius> I checked with ko1 and he said object_id doesn't pin objects, so could objects be reporting different values for that over time?
<headius> he said it will probably pin objects as Aaron's compaction work progresses
<lopex> so, leak ?
<headius> well that's unclear
<headius> I'm not sure how they'll cope with it
<lopex> at least there's no ivars for immediates too
<lopex> or at least fixnums
<headius> it's going to break eventually, or else have a huge perf penalty if they make it safe
<lopex> symbols als had ivars afair
<headius> they're frozen now
<headius> in theory that should mean no ivars
<lopex> the fixnum ivars was the leakiest thing ever
<mengu> so is it newrelic blocking things?
<mengu> i've uploadded the stacktrace to fastthread.io
<mengu> lopex: which condition variable
rdubya has quit [Ping timeout: 268 seconds]
<mengu> lopex: oh, you mean org.jruby.ext.thread.ConditionVariable
<lopex> mengu: ask headius
<headius> so newrelic is still in the app?
<mengu> let me fetch a new build
<lopex> mengu: and clean tomcat
<headius> neat site
<lopex> mengu: are you running an exploded war ?
<mengu> lopex: you mean an extracted war?
<lopex> yes
<mengu> yes
<lopex> in the past tomcat was sometimes confused about if to redeploy the app
<headius> activesupport-5.2.0/lib/active_support/concurrency/share_lock.rb:221
<headius> that's suspicious
<lopex> so AR ?
<headius> I think there's a deadlock somewhere
<headius> mengu: set JVM property jruby.jit.threshold=0 somewhere for that tomcat process and get a new dump
<headius> we can get rid of most of the interpreter lines here
<mengu> headius: i'm building a new docker image for the app
<mengu> headius: or i can do it rn?
<mengu> headius: i'm passing it through JRUBY_OPTS
<mengu> is that ok?
<mengu> with -D
<mengu> export JAVA_OPTS="$JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -Xms1024m -Xmx4096m -XX:+UseConcMarkSweepGC -Djruby.jit.threshold=0"
<headius> yeah
<headius> that works
<mengu> i'm uploading
<mengu> huh, gist cut it
<mengu> would it be related to AR timeout/checkout_timeout?
<headius> could be
<headius> /opt/tomcat/webapps/ROOT/WEB-INF/gems/gems/activesupport-5.2.0/lib/active_support/dependencies.rb:37)
<headius> this is still during boot
<headius> they're all sitting there locked on some internal monitor during boot
<headius> @lock.exclusive(purpose: :load, compatible: [:load], after_compatible: [:load])
<headius> it's some kind of load lock in rails
<mengu> and since this happened
<mengu> after i do this:
<mengu> production:
<mengu> timeout: 10000
<mengu> checkout_timeout: 10000
<mengu> adapter: postgresql
<mengu> jndi: java:/comp/env/jdbc/voiceDB
<mengu> this is probably related
<headius> what are those timeouts about?
<mengu> AR timeout for getting a connection
<mengu> interesting
<mengu> i've created a new docker container
<mengu> without newrelic
<mengu> 0 problems rn
<mengu> no choking etc
<mengu> let me load test it
<headius> yeah look at the lock report below
<mengu> Complete requests: 2000
<mengu> Failed requests: 87
<mengu> i can live with that i think, with 2 core ec2 instance
<headius> oh is it working with new relic removed?
<headius> it's not frozen anymore?