InterProScan 5.21.60.0 - Cannot initialise Java VM on nodes

[andrewprovis]

I can install InterProScan via alces gridware install and I can run the template script included via alces template on the login node. However, the application appears to fail when run via qsub.

=======================================================
SGE job submitted on Tue 17 Jan 12:35:51 UTC 2017
JOB ID: 2
JOB NAME: iprscan
PE: smp-verbose
QUEUE: byslot.q
MASTER flight-021.Jenkins.prv.alces.network
=======================================================

** A machine file has been written to /tmp/sge.machines.2 on flight-021.Jenkins.prv.alces.network **

=======================================================
If an output file was specified on job submission
Job Output Follows:
=======================================================

Installing distro dependency (1/1): java-1.8.0-openjdk ... OK
‘/opt/gridware/depots/b70ba1dc/el7/pkg/apps/iprscan/5.21.60.0/gcc-4.8.5/test/test_proteins.fasta’ -> ‘/home/alces/iprscan/input/test_proteins.fasta’
Error occurred during initialization of VM
Could not reserve enough space for 2097152KB object heap

------------------------
 InterProScan completed
------------------------
 Output is available in: /home/alces/iprscan/output.2
==================================================
SGE job completed on Tue 17 Jan 12:36:19 UTC 2017
==================================================

This was on a node with 30GB of memory available.

[alces@login1(Jenkins) ~]$ qhost
HOSTNAME                ARCH         NCPU  LOAD  MEMTOT  MEMUSE  SWAPTO  SWAPUS
-------------------------------------------------------------------------------
global                  -               -     -       -       -       -       -
flight-021              linux-x64       4  0.09   29.6G  401.3M     0.0     0.0

Is there any idea what may be causing this?

[mjtko]

Java doesn't play nicely with memory limits imposed by the scheduler. You'll need to make sure that the Java invocation is using something like java -Xmx2g to work around that.

Our usual pattern for this (when dealing with directly launched Java apps) is to create a wrapper script that makes sure this happens:

cat <<\EOF > <%= dest_dir %>/bin/picard
#!/bin/bash
exec $MYAPP_JAVA_HOME/bin/java `eval echo $MYAPP_JAVA_OPTS` -jar "<%= dest_dir %>/java/myapp.jar" "$@"
EOF

Where MYAPP is replaced by the application name and myapp.jar is replaced by the appropriately named jar file.

Then in the modulefile we do:

set JAVA_OPTS \$${appcaps}_JAVA_OPTS

<% java_home = ENV['JAVA_HOME'] || '/usr/lib/jvm/jre-1.8.0' %>
setenv ${appcaps}_JAVA_HOME <%= java_home %>
setenv ${appcaps}_JAVA_MEM_MX 2g

if { [info exists ::env(GRIDWARE_TMPDIR)] } {
  setenv ${appcaps}_JAVA_TMPDIR $::env(GRIDWARE_TMPDIR)
} elseif { [info exists ::env(TMPDIR)] } {
  setenv ${appcaps}_JAVA_TMPDIR $::env(TMPDIR)
} else {
  setenv ${appcaps}_JAVA_TMPDIR "/tmp"
}

setenv ${appcaps}_JAVA_OPTS "-Xmx\$${appcaps}_JAVA_MEM_MX -Djava.io.tmpdir=\$${appcaps}_JAVA_TMPDIR"

Might need patching some of the internal scripts of the package to make this happen -- I'm not sure of the specifics of this app.