Forum: JRuby Troubleshooting Spree on jRuby

2b278c107736b3ded0bceba25d530e3f?d=identicon&s=25 Stefan Wrobel (Guest)
on 2013-09-26 01:39
(Received via mailing list)
I've been trying for a long time to get Spree
<http://spreecommerce.com/>running on jRuby and we've landed a bunch
of commits to get to the point
where the app will boot. I've been running locally on my Mac with Spree
2.0.4/Rails 3.2.14/Puma 2.6 with jRuby 1.7.4 in Ruby 1.9.3 mode locally,
both with config.threadsafe! on & off. All has been well, so I attempted
to
deploy to Heroku, which is where things went off the rails. Many times
the
app times out on boot, which is frustrating, but when it does boot, I
get
the following very bizarre crash:
https://gist.github.com/swrobel/ea48858e421b5ceb2a43

I've tried w/ config.threadsafe! on & off and it occurs in both cases,
so
it doesn't seem to be a threadsafety issue. I've tried with both
Kaminari
(Spree dependency) versions 0.14.1 (latest gem) and github master which
seems to have some threadsafety fixes. Not quite sure how to triage
since I
don't seem able to reproduce locally no matter what I try.

I figured this was just pushing too hard to get something to run on
jRuby
that just isn't meant for it, but listening to Charles Nutter's Ruby
Rogues
appearance inspired me to open the discussion here to see if anyone can
help triage. I definitely thing jRuby is what Spree needs to run
manageably
at scale.
1273e5c266e0c4cc4065fff3a6fe7056?d=identicon&s=25 Anthony Juckel (Guest)
on 2013-09-26 02:48
(Received via mailing list)
It definitely sounds like a thread-safety issue to me, which is probably
why you're having such a hard time replicating it.  It is definitely the
Right Thing (tm) to use config.threadsafe!, but not entirely surprising
that it doesn't solve all threading concerns.  I'm curious to know if
that
backtrace was from a time when you had config.threadsafe! on or off.
302c6c56b99912a673f1213b0709c902?d=identicon&s=25 Alex Tambellini (Guest)
on 2013-09-26 03:26
(Received via mailing list)
This looks like it is a bug and is already fixed in jruby master and
will be included in jruby 1.7.5:

https://github.com/jruby/jruby/issues/927
302c6c56b99912a673f1213b0709c902?d=identicon&s=25 Alex Tambellini (Guest)
on 2013-09-26 03:30
(Received via mailing list)
Also, I think you can work around this bug by disabling invokedynamic:

https://github.com/jruby/jruby/issues/802
1273e5c266e0c4cc4065fff3a6fe7056?d=identicon&s=25 Anthony Juckel (Guest)
on 2013-09-26 05:22
(Received via mailing list)
Ah, JIT issue, not thread issue.  Try heroku config:add
JRUBY_OPTS="-Xcompile.invokedynamic=false" (from the issue Alex linked)
and
see if that fixes your heroku deploy, leaving config.threadsafe! in
place.
Also, I think you can work around this bug by disabling invokedynamic:

https://github.com/jruby/jruby/issues/802

On Sep 25, 2013, at 9:25 PM, Alex Tambellini <atambellini@gmail.com>
wrote:

This looks like it is a bug and is already fixed in jruby master and
will
be included in jruby 1.7.5:

https://github.com/jruby/jruby/issues/927


On Sep 25, 2013, at 8:47 PM, Anthony Juckel <ajuckel@gmail.com> wrote:

It definitely sounds like a thread-safety issue to me, which is probably
why you're having such a hard time replicating it.  It is definitely the
Right Thing (tm) to use config.threadsafe!, but not entirely surprising
that it doesn't solve all threading concerns.  I'm curious to know if
that
backtrace was from a time when you had config.threadsafe! on or off.
2b278c107736b3ded0bceba25d530e3f?d=identicon&s=25 Stefan Wrobel (Guest)
on 2013-09-26 18:17
(Received via mailing list)
Thanks for the suggestion! JRUBY_OPTS="-Xcompile.invokedynamic=false"
did
indeed fix the issue and the app serves requests. However, I was under
the
impression that invokedynamic was disabled by default on jruby
1.7.4/openjdk 7. Is that not the case?

Now on to troubleshooting why the app will only boot within Heroku's 60s
limit 1 out of 10 times... Any suggestions there?


--
Stefan Wrobel
CTO, CultCosmetics.com <https://www.cultcosmetics.com>
(949) 394-8728
40e5e9fe36a1f85166493faac2c17499?d=identicon&s=25 Hirotsugu Asari (Guest)
on 2013-09-26 18:33
(Received via mailing list)
Attachment: signature.asc (494 Bytes)
On Sep 26, 2013, at 12:07 PM, Stefan Wrobel <stefan@cultcosmetics.com>
wrote:

> Thanks for the suggestion! JRUBY_OPTS="-Xcompile.invokedynamic=false" did indeed
fix the issue and the app serves requests. However, I was under the impression
that invokedynamic was disabled by default on jruby 1.7.4/openjdk 7. Is that not
the case?

It was enabled for 7u40 and up on 1.7.4, in the hopes that it was going
to be stable enough. We were wrong. 1.7.5 will disable InvokeDynamic on
all Java 7 versions.
40e5e9fe36a1f85166493faac2c17499?d=identicon&s=25 Hirotsugu Asari (Guest)
on 2013-09-26 18:35
(Received via mailing list)
Attachment: signature.asc (494 Bytes)
On Sep 26, 2013, at 12:25 PM, Hirotsugu Asari <asari.ruby@gmail.com>
wrote:

>
> On Sep 26, 2013, at 12:07 PM, Stefan Wrobel <stefan@cultcosmetics.com> wrote:
>
>> Thanks for the suggestion! JRUBY_OPTS="-Xcompile.invokedynamic=false" did
indeed fix the issue and the app serves requests. However, I was under the
impression that invokedynamic was disabled by default on jruby 1.7.4/openjdk 7. 
Is
that not the case?
>
> It was enabled for 7u40 and up on 1.7.4, in the hopes that it was going to be
stable enough. We were wrong. 1.7.5 will disable InvokeDynamic on all Java 7
versions.

*disable by default*
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.