Currently, the scout_apm gem does not install on JRuby, since it references C extensions.
We have 2 C extensions in the mainline gem right now (and ScoutProf in the 3.x branch uses a C ext as well).
Both of the C extensions are related to memory usage:
Allocations - hooks to count allocations over a time frame.
Rusage - a vendored version of a tiny C ext for determining memory usage of the process.
Both of these are easily stubbed to return 0s, allowing the rest of the agent to work as normal. In addition, it's likely that Java contains APIs to get similar data out of the VM.
The big issue is that there doesn't seem to be any way to mark a C extension as optional for the gem. Ideally, we'd say: "do your best to build this C ext, but if not, the gem will continue to work w/ fallback code", but that doesn't seem to exist.
Other gems (like concurrent-ruby) ship an additional C ext gem (concurrent-ruby-ext). So the base gem is pure ruby, then a layered on version with C exts. This approach is a bit awkward for us, since we want our install process to be as simple and error-resistant as possible. Asking for 2 distinct gems to be installed will inevitably cause issues.
Brainstorming Approaches:
scout_apm_ruby is a gem with C ext, but not most of the agent code, it could reference the bulk of the agent code in a new scout_apm_ruby_core. Jruby support would be referencing the_core library directly, or perhaps a new _jruby build with custom JVM-specific support.
scout_apm_ruby could have a branch on github, tracking the mainline code but removing C extensions. Unsure if we'd release it directly, or just have it available in git for users to point bundler at.
Find a way to optionally build the C exts
A fancier build script which releases the normal gem, then applies JRuby patches to the code automatically and releases a _jruby version of the gem with the same version number.
Currently, the
scout_apm
gem does not install on JRuby, since it references C extensions.We have 2 C extensions in the mainline gem right now (and ScoutProf in the 3.x branch uses a C ext as well).
Both of the C extensions are related to memory usage:
Both of these are easily stubbed to return 0s, allowing the rest of the agent to work as normal. In addition, it's likely that Java contains APIs to get similar data out of the VM.
The big issue is that there doesn't seem to be any way to mark a C extension as optional for the gem. Ideally, we'd say: "do your best to build this C ext, but if not, the gem will continue to work w/ fallback code", but that doesn't seem to exist.
Other gems (like
concurrent-ruby
) ship an additional C ext gem (concurrent-ruby-ext
). So the base gem is pure ruby, then a layered on version with C exts. This approach is a bit awkward for us, since we want our install process to be as simple and error-resistant as possible. Asking for 2 distinct gems to be installed will inevitably cause issues.Brainstorming Approaches:
scout_apm_ruby
is a gem with C ext, but not most of the agent code, it could reference the bulk of the agent code in a newscout_apm_ruby_core
. Jruby support would be referencing the_core
library directly, or perhaps a new_jruby
build with custom JVM-specific support.scout_apm_ruby
could have a branch on github, tracking the mainline code but removing C extensions. Unsure if we'd release it directly, or just have it available in git for users to point bundler at._jruby
version of the gem with the same version number.