• New Feature
  • Status: Open
  • 2 Major
  • Resolution:
  • prodmgmt
  • Reporter: sergiob
  • October 03, 2008
  • 0
  • Watchers: 3
  • March 10, 2011



HP-UX is currently unsupported due to its vendor-specific JVM, but it seems to be a problem related to version/vendor information parsing.

So, I’ve successfully patched the following sources (see attachments for diffs):

  • com.tc.util.runtime.VmVersion
  • com.tc.util.VendorVmSignature And rebuilt the whole Terracotta package.

Now, Terracotta server and client properly start and work, at least by testing them through the “coordination” sample.

I just get the following exception, which shouldn’t affect anything other than statistics:

9224 [main] DEBUG Sigar - no libsigar-ia64-hpux-11.sl in java.library.path org.hyperic.sigar.SigarException: no libsigar-ia64-hpux-11.sl in java.library.path at org.hyperic.sigar.Sigar.loadLibrary(Sigar.java:160) at org.hyperic.sigar.Sigar.(Sigar.java:90) at com.tc.statistics.retrieval.actions.SRACpu.(SRACpu.java:25) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at java.lang.Class.newInstance0(Class.java:354) at java.lang.Class.newInstance(Class.java:307) at com.tc.statistics.retrieval.impl.StatisticsRetrievalRegistryImpl.registerActionInstance(StatisticsRetrievalRegistryImpl.java:53) at com.tc.object.DistributedObjectClient.populateStatisticsRetrievalRegistry(DistributedObjectClient.java:229) at com.tc.object.DistributedObjectClient.start(DistributedObjectClient.java:361) at com.tc.object.bytecode.ManagerImpl$2.execute(ManagerImpl.java:175) at com.tc.lang.StartupHelper.startUp(StartupHelper.java:39) at com.tc.object.bytecode.ManagerImpl.startClient(ManagerImpl.java:188) at com.tc.object.bytecode.ManagerImpl.init(ManagerImpl.java:130) at com.tc.object.bytecode.ManagerImpl.init(ManagerImpl.java:118) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.createGlobalContext(ClassProcessorHelper.java:634) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.init(ClassProcessorHelper.java:421) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.systemLoaderInitialized(ClassProcessorHelper.java:795) at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1327) at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1286)


Taylor Gautier 2008-10-03

Can you verify what JVM is being used? Is it a HotSpot VM?

Sergio Bossa 2008-10-03

Yes, it is, but shipped by HP:

java version “” Java(TM) 2 Runtime Environment, Standard Edition (build Java HotSpot(TM) Server VM (build jinteg:11.07.07-16:23 IA64, mixed mode)

Is it enough?

Alex Miller 2008-10-03

Seems to me like it would be ok to commit these without adding official support.

Walter Harley 2008-10-03

Re the SigarException, see also bug CDV-877

Sergio Bossa 2008-10-08

FYI: the Terracotta-based clustered Jira version seems to properly work on HP-UX with the patches above, which is a very good thing, given that it’s not a “trivial” Terracotta application.

Bob Butash 2011-03-10

Need some additional help here if possible.

I followed the modifications above, and I was able to successfully start the caching server on an HP-UX box.

However, I have the application also running on an HP-UX box and when the application is deployed it attempts to make the connection to the caching server. It appears that it is not picking up my changed class on the client connection, as the line number of the RuntimeException that is thrown due to an unknown version number, line 91, matches to the original codebase and not the altered code base.

I altered the two classes above and placed them in a separate jar file that I added to the class path prior to the tc.jar file in the server startup script, since that did not work I overlayed the files directly in the tc.jar file. Still no luck, it is picking up the original class at client start up. However this class does not appear to be in any other jar file that is deployed.

Assistance would be greatly appreciated.