drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
shellac has quit [Quit: Computer has gone to sleep.]
_whitelogger has joined #jruby
shellac has joined #jruby
drbobbeaty has joined #jruby
ezzeddine[m] has quit [Remote host closed the connection]
TimGitter[m] has quit [Remote host closed the connection]
lopex[m] has quit [Remote host closed the connection]
UweKuboschGitter has quit [Remote host closed the connection]
headius[m] has quit [Remote host closed the connection]
elia_[m] has quit [Remote host closed the connection]
TimGitter[m]1 has quit [Remote host closed the connection]
FlorianDoubletGi has quit [Remote host closed the connection]
ChrisSeatonGitte has quit [Read error: Connection reset by peer]
enebo[m] has quit [Remote host closed the connection]
ThomasEEneboGitt has quit [Remote host closed the connection]
JulesIvanicGitte has quit [Remote host closed the connection]
olleolleolle[m] has quit [Read error: Connection reset by peer]
donv[m] has quit [Remote host closed the connection]
anubhav8421[m] has quit [Read error: Connection reset by peer]
OlleJonssonGitte has quit [Read error: Connection reset by peer]
BlaneDabneyGitte has quit [Remote host closed the connection]
cshupp[m] has quit [Remote host closed the connection]
brodock[m] has quit [Read error: Connection reset by peer]
asp_ has quit [Write error: Connection reset by peer]
vs-de[m] has quit [Write error: Connection reset by peer]
metafr[m] has quit [Read error: Connection reset by peer]
RomainManni-Buca has quit [Remote host closed the connection]
rdubya[m] has quit [Remote host closed the connection]
cbruckmayer[m] has quit [Remote host closed the connection]
liamwhiteGitter[ has quit [Remote host closed the connection]
CharlesOliverNut has quit [Read error: Connection reset by peer]
MarcinMielyskiGi has quit [Read error: Connection reset by peer]
voloyev[m] has quit [Read error: Connection reset by peer]
kares[m] has quit [Remote host closed the connection]
mattpatt[m] has quit [Remote host closed the connection]
XavierNoriaGitte has quit [Remote host closed the connection]
MattPattersonGit has quit [Remote host closed the connection]
KarolBucekGitter has quit [Remote host closed the connection]
JesseChavezGitte has quit [Remote host closed the connection]
dsisnero[m] has quit [Remote host closed the connection]
dsisnero[m] has joined #jruby
asp_ has joined #jruby
lopex[m] has joined #jruby
sandio[m] has joined #jruby
cbruckmayer[m] has joined #jruby
JesseChavezGitte has joined #jruby
vs-de[m] has joined #jruby
RomainManni-Buca has joined #jruby
FlorianDoubletGi has joined #jruby
TimGitter[m]1 has joined #jruby
ChrisSeatonGitte has joined #jruby
TimGitter[m] has joined #jruby
kares[m] has joined #jruby
elia_[m] has joined #jruby
headius[m] has joined #jruby
ezzeddine[m] has joined #jruby
metafr[m] has joined #jruby
cshupp[m] has joined #jruby
KarolBucekGitter has joined #jruby
XavierNoriaGitte has joined #jruby
mattpatt[m] has joined #jruby
brodock[m] has joined #jruby
OlleJonssonGitte has joined #jruby
olleolleolle[m] has joined #jruby
liamwhiteGitter[ has joined #jruby
JulesIvanicGitte has joined #jruby
anubhav8421[m] has joined #jruby
voloyev[m] has joined #jruby
enebo[m] has joined #jruby
CharlesOliverNut has joined #jruby
BlaneDabneyGitte has joined #jruby
MattPattersonGit has joined #jruby
UweKuboschGitter has joined #jruby
MarcinMielyskiGi has joined #jruby
donv[m] has joined #jruby
rdubya[m] has joined #jruby
ThomasEEneboGitt has joined #jruby
lucasb has joined #jruby
hosiawak has joined #jruby
<hosiawak>
What's the recommended way to run JRuby on Rails in production ? I looked at Warbler but it creates a .war file that exits with a cryptic Rack error when deployed to Tomcat. I looked at Torquebox but turns out the project is no longer maintained. Any other options ?
<hosiawak>
or is there a way to create the working .war file (Rails 6.0) myself ?
<hosiawak>
headius[m]: just wondering if there are any other methods to create a working .war file ? Warbler doesn't seem like it's maintained anymore too
<headius[m]>
for purposes of benchmarking the web framework, though, keepalive makes more sense
<headius[m]>
we're not benchmarking socket establishment
subbu|lunch is now known as subbu
cpuguy83 has quit [Remote host closed the connection]
cpuguy83 has joined #jruby
<headius[m]>
hmm that's not helping me on my EC2 rig
cpuguy83 has quit [Ping timeout: 240 seconds]
subbu is now known as subbu|away
<kares[m]>
enebo: yes pretty much interrupting long regexps
<headius[m]>
maybe we need to figure out a way to timeout regexp based on some instruction limit 😟
<enebo>
or we build in timeout with interuptible as a feature
<enebo>
to joni
<enebo>
Assume with that feature enabled there is some price to regexp which costs a bit more but much less than using timeout + interupting
cpuguy83 has joined #jruby
<headius[m]>
there's not a lot of good options here
<headius[m]>
MRI's timeout is dirt stupid...if they could interrupt regexp it would be a million times more overhead thanus
<headius[m]>
than us
<enebo>
I am suggesting an extended API for this which would bake timeouts into joni
<headius[m]>
oh you know what
<headius[m]>
stupid idea: timeout sets an end time whenit starts and joni checks that periodically
<headius[m]>
no threads or scheduling involved
<headius[m]>
joni kills itself
<enebo>
yeah
<headius[m]>
my first thought when you suggested joni do it was "wouldn't it be just as bad if joni used a scheduled pool"
<headius[m]>
that's not a bad idea
<headius[m]>
it would mean more API expansion, to support both thread timeout and "finish before" timeout
<enebo>
I was thinking in comparison to timeout a nanotime every so often (probably occasional backedge instr check)
<headius[m]>
this lib will have everything soon
<enebo>
we can also completely separate the engine for this if it somehow complicates the common path one too
<enebo>
lopex already has multiple instr engines in it
<headius[m]>
that's true
<headius[m]>
lopex: ping!
subbu|away is now known as subbu
<headius[m]>
kares: this might be a path
<headius[m]>
no timeout at all
<headius[m]>
I mean no timeout lib...you'd have to do .match(str, millis) or something
<enebo>
yeah
<headius[m]>
enebo: that's another wrinkle since it would necessitate a custom API
<enebo>
yeah but I am ok with providing a JRuby-specific API and then submitting a API req to MRI to add it
<enebo>
I am sure logstash will do it if it massively improves perf
<enebo>
which if you are submitting 1000s of threads for this it should be mighty
<kares[m]>
interesting
<headius[m]>
kares: sort of like an instruction limit but not as wonky
<kares[m]>
do not want to hard push this ... unless of course there's a use-case (benefit) for others as well
<kares[m]>
and it doesnot effect performance
<headius[m]>
enebo: why did interrupt checking slow things down? Because we're pinging it periodically?
<kares[m]>
yeah there's checking through the loop
<kares[m]>
for interrupts
<headius[m]>
I'm trying to remember why we didn't just add an interrupt-check instruction and only compile that in when you ask for interruptibility
<headius[m]>
maybe we couldn't figure out where the instruction should go
<kares[m]>
that would be interesting
<enebo>
It was more than that
<enebo>
it was not the joni loop which was the issue as much as it was us wrapping that joni run in something to catch the interrupt
<enebo>
so we fast pathed around the stuff setting up the try catch but then also made a more obvious fast and slow path into joni
<enebo>
It is possible we could reduce the interrupt cost by more analysis in which back edge ish crap exists and check less
<enebo>
but it is a natural place to do a time comparison as well
<enebo>
I don't fully remember all the details though
<headius[m]>
yeah back edge would be great if that's something we can determine
<headius[m]>
so we add a timeout or interrupt ping on backedge only if requested and then non-timeout is unaffected
<enebo>
This is not really a priority for me next couple of weeks but lopex definitely knows how to add this
<enebo>
Optimizing both features to be better than it is today for interruptable may be in the cards but we can get a quick win just adding in the timing check to where we have interupt code and just add a new path into joni
<headius[m]>
yeah indeed
<headius[m]>
kares: like enebo says not a high priority for us (maybe no priority) but it's a possible path forward if other options fall apart
<headius[m]>
driven by Elastic obviously
<headius[m]>
Jordan added the interrupt stuff initially I believe
<lopex>
add what ?
<enebo>
lopex: explicit timeout: time option to joni
<enebo>
lopex: nanotime or something at same place as interupt check to exit if too much time has passed
<lopex>
ah, yeah
<enebo>
lopex: logstash is making potentially 1000s of timeouts around regexps and that is obviously really expensive
<enebo>
kares[m]: lopex: I think if you guys want to add this it is a great idea. I am just busy for rubyconf prep atm. Bonus for considering adding an RFE to ruby-lang as well.
<headius[m]>
yeah this would might be motivation for them to add some sort of timeout too
cpuguy83 has quit [Ping timeout: 265 seconds]
<headius[m]>
the way we have it now I'm not sure they can do it because it would require onigmo to know about MRI internals more than it does now, but just adding an end time to onigmo might be easier
<lopex>
how expensive is nano though ?
<lopex>
it would have to be read every threashold we have for interrupt right ?
<enebo>
lopex: much less expensive than setting up a thread and interrupting
<enebo>
lopex: I do not understand that question
<enebo>
lopex: I do not remember how often we check interrupt but it need not be once per ip in the interpreter of joni...
<lopex>
so, yeah, every that amount we have for interrupts right ?
<lopex>
or more often ?
<enebo>
lopex: no I do not think this need to be all that precise
<enebo>
lopex: I would be inclined to do it in same place as interrupt check for starters and we can maybe analyze if we can do something more crafty later
<enebo>
lopex: if you add it there and nanotime is obnoxiously expensive then I guess it will make us consider how good a feature it is OR look into a way of checking less often
<lopex>
not sure how up to date it is
<enebo>
lopex: bah who cares...just use it in same place we check and see if you can even tell
<enebo>
out default is more or less every 30k joni instrs
<enebo>
I do wonder now that I have not thought about this if we could identify the back edges of joni instrs
<enebo>
and I am not sure what backedges are in joni instr but places where it leads to backtracking would be an obvious place
<lopex>
so pushes...
<enebo>
An infinite string with a simple kleene match would never be checked but I doubt something like that is realistically ever an interuptible case
<enebo>
could be...I am not familiar with the instr set past these every one year conversations we have :)
<lopex>
pushAlt to be more specific
<enebo>
lopex: but for now I am curious what impact can be seen from even checking nanotime every 30k instrs
cpuguy83 has joined #jruby
<headius[m]>
I thought there had been some improvements to this nanotime thing but I don't recall
<headius[m]>
I remember discussions years ago about what that article discusses, specifically monotonicity across threads (or lack of)
<headius[m]>
if I remember right nanotime was really slow at some point because it actually tried to sync threads
<headius[m]>
pretty sure Cliff Click did a talk about it
<headius[m]>
Cliff or Gil
cpuguy83 has quit [Ping timeout: 240 seconds]
<headius[m]>
in any case this is a cost Elastic would opt-into if we could make it an instruction
<headius[m]>
I was just trying to remember why we didn't do that for the thread ping
<enebo>
we did not use it once because of VMs pausing
<enebo>
but an interupt on a regexp paused while a VM is paused may just be the tradeoff you accept
<headius[m]>
yeah we're not talking about timeouts in the minutes or hours
<headius[m]>
if someone closes the lid while your 500ms regexp runs I think you accept that it's going to time out
<headius[m]>
or not
<headius[m]>
but won't be predictable
<enebo>
yeah it may never interrupt but that's life
<headius[m]>
`QueryPerformanceCounter(¤t_count);`
<headius[m]>
what syntax is that 😳
<headius[m]>
from that article
<enebo>
heh we could add a second conditional looking to see if nanotime < savedchecktime
cpuguy83 has joined #jruby
<enebo>
and interupt because it paused and then came back with something completely different
<headius[m]>
yeah that would be the simple way
<headius[m]>
so it starts out with (string, timeout) and interrupts if nanoTime exceeds startNanoTime + timeout
<enebo>
yeah or somehow ends up less than start
<enebo>
OR we reset it to start
<enebo>
in any case that is way too corner case to worry about for this
<headius[m]>
yeah nanoTime must be within [startTime, startTime + timeout]
<headius[m]>
heh yeah
<enebo>
in the use of JIT threshold it mainly just means nothing will jit from that point forward
<headius[m]>
anyway I assume kares will communicate this back as another path forward
<headius[m]>
I just want to figure out this blasted 40ms thing
<enebo>
and I am not positive we can see it be smaller or not.
<enebo>
yeah me too
<headius[m]>
ugh, search for jvm and latency and every article is about GC
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
hosiawak has quit [Ping timeout: 240 seconds]
hosiawak has joined #jruby
hosiawak has quit [Ping timeout: 276 seconds]
hosiawak has joined #jruby
hosiawak has quit [Ping timeout: 265 seconds]
hosiawak has joined #jruby
hosiawak has quit [Ping timeout: 240 seconds]
hosiawak has joined #jruby
lucasb has quit [Quit: Connection closed for inactivity]