Jim
|
Posted: January 23, 2012 16:43 by Jim
|
|
Hello, We are exploring various MPI implementations, including OpenEMPI. Even though the instructions page states: "The war file can be deployed on any container that supports the deployment of WAR files..." we have been running into a variety of deployment issue under GlassFish, both 2.x and 3.x. Browsing through the forums leads me to think that perhaps OpenEMPI is limited in deployment options. I am coming across statements that lead me to some troubling conclusions. I would love to see these conclusions disproved, or at least rationalized:
I conclude from the above that OpenEMPI works only on specific (now ancient) technologies. JBoss 4.2.3 is an app server implementation for Java EE 1.4 (now 10 years old), so it should not be surprising that more recent application servers implementing Java 1.5 or Java 1.6 would have troubles. Has anyone is the community successfully deployed OpenEMPI on any application server that is Java 5 or Java 6 based? I hope that I am wrong in my conclusions, and that someone can put clarity to my observations, and reading of the documentation. Thank you for your time. -- Jim |
Request clarification on deployment requirements.
by: Jim
|
odysseas
|
Posted: January 25, 2012 01:11 by odysseas
|
|
Jim, The war file can be deployed on any web container and we have it running on Tomcat, Glassfish and newer versions of JBoss. You need to set the environment variable OPENEMPI_HOME to point to the directory where the OpenEMPI distribution was expanded into. What error message are you seeing with Glassfish? Odysseas |
|
Jim
|
Posted: January 26, 2012 16:30 by Jim
|
|
Hi Odysseas, Thanks so much for responding. First, for both GlassFish 2.x and 3.x, the following applies: We do indeed have the environment variable OPENEMPI_HOME set to the parent directory of where the file was extracted, in our case, we downloaded : and extracted to which had a directory structure of root@OpenEMPI-2 /opt/openempi-2.2.0# ls -1 so our /etc/profile.d/myprofile.sh script has: For both versions we also opted to start off with the easiest path, and so we autodeployed the WAR file. Also, for both versions the only other modification was to the file where we changed the to point to our PostGreSql server. From there our results for each GlassFish version diverge substantially. The server.log files tend to be rather long, with SEVERE tags that do the cascade thing that go on and on. So, since this forum does not seem to permit attachments, I am going to be considerate of my fellow If you would rather that you have the whole log file, I can certainly forward that to you, out-of-band (jimkfoster@gmail.com). GlassFish 2.1:According to the console, GlassFish appears to start up ok. However, the server.log tells a different story, and appears to originate with a problem with transactionManager. [1] [#|2012-01-23T08:48:21.861+0000|SEVERE|sun-appserver2.1|javax.enterprise.system.container.web|ThreadID=10;ThreadName=main;_RequestID=6ee8688c-9341-4c8e-9a68-56da3c9b3680;|WebModule[/openempi-webapp-web-2.2.0]StandardWrapper.Throwablejava.lang.NullPointerException at org.openempi.webapp.server.AdminServiceImpl.init(AdminServiceImpl.java:45) [2] [#|2012-01-23T08:48:21.867+0000|SEVERE|sun-appserver2.1|javax.enterprise.system.container.web|ThreadID=10;ThreadName=main;_RequestID=6ee8688c-9341-4c8e-9a68-56da3c9b3680;|WebModule[/openempi-webapp-web-2.2.0]PWC1396: Servlet /openempi-webapp-web-2.2.0 threw load() exceptionjava.lang.NullPointerException at org.openempi.webapp.server.AdminServiceImpl.init(AdminServiceImpl.java:45) [3] [#|2012-01-23T08:48:21.915+0000|SEVERE|sun-appserver2.1|javax.enterprise.system.container.web|ThreadID=10;ThreadName=main;_RequestID=6ee8688c-9341-4c8e-9a68-56da3c9b3680;|WEB0207: Error starting web context StandardEngine[com.sun.appserv].StandardHost[server].StandardContext[/openempi-webapp-web-2.2.0] on virtual server serverLifecycleException: java.lang.NullPointerException at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4979 GlassFish 3.1:According to the console, GlassFish appears to start up ok. However, autodeploy of the WAR file throws v3 into a loop that is unrecoverable. The server.log file has but one SEVERE tag: [#|2012-01-26T08:07:37.421-0700|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|ThreadID=41;ThreadName=Thread-1;|java.net.MalformedURLException: Bad host: "OpenEMPI-2.2.0-Baseline-GF31"
at javax.management.remote.JMXServiceURL.validateHost(JMXServiceURL.java:459)
at javax.management.remote.JMXServiceURL.validateHost(JMXServiceURL.java:361)
at javax.management.remote.JMXServiceURL.validate(JMXServiceURL.java:337)
at javax.management.remote.JMXServiceURL. I'm not sure what to make of the statement It is the name of the server and has its entry in resolv.conf as well as the DNS machine on this local network. I suspect that it is a GlassFish-specific configuration thing, and has nothing at all to do with OpenEMPI, itself. ----- Anything jump out at you that would lend some insight as to steps forward? Thanks for you time, Odysseas. I very much appreciate it. -- Jim |
|
odysseas
|
Posted: January 26, 2012 19:33 by odysseas
|
|
Jim, Glassfish 2.1 needed some customization of the domain's configuration to get the deployment to work. There may be a better way to do this, and if you find a better way please share it with us, but here is how we got OpenEMPI running on Glassfish. First, you need to copy the log4j.properties file from the OpenEMPI home directory to the domain1/lib/classes. This will allow Glassfish to find it during deployment of the war file and you will be able to see in the openempi.log file why the deployment is failing (if it still is by the time we are done). Then you need to add some of the OpenEMPI jar file to the classpath since they seem to conflict with those used by the Glassfish app server itself. You need to add the classpath-prefix attribute in the java-config element of your domain.xml file and also make sure that you copy the listed jar file to the domain/domain1/lib directory. I truncated many of the jvm-options below so you don't have to remove any of the default options in that section of the XML file. We also added the openempi.home system variable to ensure that the environment for OpenEMPI is setup properly.
<java-config classpath-suffix="" debug-enabled="true" debug-options="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=9009" env-classpath-ignored="false" java-home="${com.sun.aas.javaRoot}" javac-options="-g" rmic-options="-iiop -poa -alwaysgenerate -keepgenerated -g" system-classpath=""
classpath-prefix="${com.sun.aas.instanceRoot}/lib/aspectjweaver-1.6.0.jar:${com.sun.aas.instanceRoot}/lib/hibernate-3.2.6.ga.jar:${com.sun.aas.instanceRoot}/lib/dom4j-1.6.1.jar:${com.sun.aas.instanceRoot}/lib/hibernate-annotations-3.3.0.ga.jar:${com.sun.aas.instanceRoot}/lib/hibernate-commons-annotations-3.3.0.ga.jar:${com.sun.aas.instanceRoot}/lib/postgresql-8.1-407.jdbc3.jar">
<!-- various required jvm-options -->
<jvm-options>-XX:MaxPermSize=192m</jvm-options>
<jvm-options>-client</jvm-options>
<jvm-options>-Dopenempi.home=/opt/openempi-2.2.0</jvm-options>
</java-config>
Let me know if this gets your instance up and running. Odysseas |
|
Jim
|
Posted: January 27, 2012 16:37 by Jim
|
|
Odysseas, Thank you for your recommendations on fixing the deploy steps to GlassFish 2.1. I followed your steps and have some feedback for you. Bad news is that there are still errors. As I did yesterday, I am going to extract from the log files where I believe the focal point of debugging effort should go, with the standing offer to send the entire log file(s) to you out-of-band. openempi.logThis one is pretty clear on what is wrong: Spring cannot create a bean, specifically, transactionManager. The following is the first ERROR encountered in openempi.log (with indentations to facilitate reading). server.logServer log has 16 SEVERE tags that point directly to catalina. Those lines are (less the cascade): I am still on the high end of the learning curve with the code base of OpenEMPI, of course, but it appears to me that one should start with nailing down that sessionFactory in applicationContext-dao.xml. Your thoughts? -- Jim |
|
odysseas
|
Posted: January 27, 2012 17:56 by odysseas
|
|
Jim, I am not sure why it is not working as I assume we are both using the same app server version but I can see that the problem you are having now is with a class loader conflict with a class from the Apache Logging framework:
Constructor threw exception;
nested exception is java.lang.NoClassDefFoundError:
org/apache/commons/logging/LogFactory
What you need to do to fix it, is copy the following jar files: commons-logging-1.1.1.jar and commons-logging-api-1.1.jar from the deployment directory under domain1/applications/j2ee-modules/../ into the domain1/lib directory and then add the name of these two jar files to the classpath-prefix attribute in the domain.xml file. This should get you past this error although you may get more of these so you may have to repeat this process iteratively until all of them are resolved. What I mean here is that if you get another NoClassDefFoundError, you need to identify the jar file that includes the missing class, move that jar file to the domain1/lib directory and add the jar name to the classpath-prefix attribute. Let me know if this helps. Odysseas |
|
Jim
|
Posted: January 30, 2012 16:08 by Jim
|
|
Hi odysseas, I have some more feedback for you. First, as to the platform I am on: GlassFish (Installed from glassfish-installer-v2.1.1-b31g-linux.jar)Java (Installed from jdk-6u26-linux-i586.bin)Linux (Ubuntu 10.04.1)or, in a more readable form:
In addition to the (6) you originally identified:
In order to move forward I used activemq-4.0.1.jar which has the required class.
Thanks! -- Jim |
|
odysseas
|
Posted: February 02, 2012 16:54 by odysseas
|
|
Jim, The dependence on the edu/emory/../AbstractExecutoreService is a result of the eh-cache library we are using: [INFO] | +- net.sf.ehcache:ehcache:jar:1.4.1:compile [INFO] | | +- net.sf.jsr107cache:jsr107cache:jar:1.0:compile [INFO] | | \- backport-util-concurrent:backport-util-concurrent:jar:3.1:compile You should have in the WEB-INF/lib directory of the openempi-webapp-web-2.2.0.war file the jar file: backport-util-concurrent:backport-util-concurrent:jar: We have been very busy with preparations for the upcoming HIMSS Conference where we will be doing a demonstration of OpenEMPI so, we haven't had much time to help you out with the install on Glassfish. Let me know if this gets you further. Odysseas |
|
Jim
|
Posted: February 03, 2012 15:11 by Jim
|
|
Hi Odysseas, I apologize that I caught you at a bad time. "There may be a better way to do this, Well, there is a better way: set an environment variable for the application classpath like so:
to
and
I am sure you will have a great showing, and I would be interested in hearing how how it turns out. Thanks for all your patient help, Odysseas! -- Jim |
by: Jim
