<Freaky> headius[m]: thought the plot thickened there, JrJackson throwing parse errors
<Freaky> but it just turns out I can't code ;)
_whitelogger has joined #jruby
<Freaky> weird serialize error
<Freaky> oh for goodness sake
<Freaky> Who's bug is it anyway
<Freaky> wtf
<Freaky> that object fails to dump to JSON
<Freaky> but only if it's in my indexing code
<Freaky> copy that into a REPL and dump it and it's fine
<headius[m]> This is exciting to observe
jeremyevans has quit [Ping timeout: 264 seconds]
<Freaky> this is the wrong type of exciting :)
<Freaky> I can reproduce this one every time, and on JVM 14, 11, and 8
<Freaky> but only in the most inconvenient place
<Freaky> right
<Freaky> it does it if I pull the data out of Postgres
<Freaky> mmm
<Freaky> hmm
<Freaky> Sequel::Postgres::PGArray
<Freaky> and indeed, .to_a on those fields and it works
<Freaky> phew
jeremyevans has joined #jruby
drbobbeaty has quit [Ping timeout: 264 seconds]
drbobbeaty has joined #jruby
den_d has quit [Ping timeout: 260 seconds]
den_d has joined #jruby
drbobbeaty has quit [Ping timeout: 260 seconds]
drbobbeaty has joined #jruby
<fidothe> More thready weirdness. I had a call to IO#puts in a `synchronize`d block for a logger so that you'd always get one and only one log entry per line, but I was still getting more than one entry on a line and occasional double newlines (no interleaved entries, which was a pre-`synchronize`problem). Switching to IO#write and adding the newline by hand seems to have fixed it
<fidothe> can `IO#puts` really not be threadsafe, even within a `Mutex` synchronised block?
<fidothe> Also, I just saw the weirdest transient error: `uninitialized constant JRuby::Type` in some enumerationrelated code
havenwood has quit [Read error: Connection reset by peer]
havenwood has joined #jruby
havenwood has quit [Changing host]
havenwood has joined #jruby
<headius[m]> That is odd
<headius[m]> No reason I can think of why puts would do that under lock
<headius[m]> Are you sure all threads using the same lock?
<headius[m]> puts basically just does print for the string and for the newline
Iambchop has quit [Read error: Connection reset by peer]
Liothen has quit [Read error: Connection reset by peer]
Iambchop has joined #jruby
Liothen has joined #jruby
<fidothe> ah, no
<fidothe> one class using `MonitorMixin`, but a bunch of instances writing to the same IO
<fidothe> I think my understanding of MonitorMixin is probably flawed
<fidothe> er.
<fidothe> actually, I'm not 100% about the implementation. I wrote it a few months back
<fidothe> Yeah, there's lots of instances writing to the same IO, so that'll be that. I guess write must be atomic at the system level so by manually adding the \n I just luck out
<headius[m]> Yeah better to have the lock in a constant
<headius[m]> It is a global lock
<fidothe> The other transient error I'm seeing seems require-related. I'm using autoload, which I thought was now threadsafe. Am I assuming wrong?
<headius[m]> It should be but there are some edges
<headius[m]> Master has a rewrite of this logic
<fidothe> I only see it maybe once or twice in a run (~2000 jobs on 20 instances each using 8 threads) so I guess you have to get really unlucky to hit whatever I'm hitting. I think I can happily wait for the next release for that...
<headius[m]> Hmm yeah that makes it a little odd... Would have thought it all loaded by then
<fidothe> a bunch of the stuff that's being autoloaded doesn't get loaded until after the worker threads are spun up and have started working, so there's scope for unlucky timing