From: Sriram K. <sr...@sd...> - 2009-06-29 17:44:51
|
> >>> Maybe it would help if I understood Java better. If I was >>> building a > Fortran/C program with autoconf, I'd expect to have to pass > configure some > option to use DRMAA. This would either produce a staticly-linked > binary that > would produce a compile-time error if it couldn't find the library, > or a > dynamically-linked binary that would produce a run-time error if it > couldn't > find the library. Whether it is using DRMAA or not is defined in the opal.properties file. You can verify that it is using DRMAA by looking at your Tomcat logs. If it is indeed using DRMAA, Opal should print the following to the log - "Using job manager class: job manager class being used". > With Tomcat, I haven't done anything to tell it to use DRMAA. There > doesn't > seem to be the equivalent of a binary that I could run 'ldd' on to > verify it > was going to use libdrmaa. Maybe that's because the support for > DRMAA is in > the Opal stuff (e.g. /webapps/opal2/WEB-INF/lib/drmaa.jar)? How can > I debug > whether Tomcat is failing to find the library? Why wouldn't Tomcat/ > Opal > complain if it couldn't find libdrmaa rather than fail silently? Ideally, it should really throw an exception. In fact, most errors are indeed logged by Opal/Tomcat. However, the DRMAA support is provided by using a 3rd party package that uses the Java Native Interface. We have noticed that it sometimes dies silently, rather than throwing a useful exception (however, this doesn't happen once DRMAA has been properly configured). In any case, do you have a line in your Tomcat log like - "Can't initialize DRMAA session:". Thanks, Sriram |