Terracotta Discussion Forums

I am able to start the Terracotta server, but when i try to run a client, i get the following
Exception in thread "main" com.tc.object.tools.UnsupportedVMException: Unknown or unsupported OS detected: FreeBSD
at com.tc.object.tools.BootJarSignature.<init>(BootJarSignature.java:23)
at com.tc.object.tools.BootJarSignature.getSignatureForThisVM(BootJarSignature.java:52)
at com.tc.object.tools.BootJarSignature.getBootJarNameForThisVM(BootJarSignature.java:61)
at com.tc.object.tools.BootJarTool.main(BootJarTool.java:2518)

If the FreeBSD is not supported, then how is the server starting up, or is there something i might be missing here

When we say "support", it means we do rigorous testing on the platform. It doesn't mean that it won't work. However, there are cases where OS sensitive info needed to be parsed, hence the exception you ran into.

Since we're open source, you're welcome to try it out and change the OS check in that piece of the code or create a JIRA issue so we might get to it.

Would definitely try and see if i can work on the code.

Has anyone run terracotta successfully on FreeBSD 5.3? it could be just a setup issue for me

Has anyone run terracotta successfully on FreeBSD 5.3

The closest I would say would be TC running on OS X (http://developer.apple.com/opensource/index.html)

To patch your copy of TC to acknowledge FreeBSD take a look at the following classes:

common/src/com/tc/util/VendorVmSignature.java
dso-l1/src/com/tc/object/tools/BootJarSignature.java
dso-l1/tests.unit/com/tc/object/tools/BootJarSignatureTest.java

I've created a JIRA for this, feel free to comment and/or post your patches: http://jira.terracotta.org/jira/browse/CDV-885

I've been working on getting terracotta running on FreeBSD 7.0. I have tc compiling and am able to run the server running tcbuild

# JAVA_HOME_16=/usr/local/diablo-jdk1.6.0 JAVA_HOME_14=/usr/local/jdk1.5.0 JAVA_HOME_15=/usr/local/jdk1.5.0 ANT_HOME=/usr/local/apache-ant ./tcbuild jdk=1.6 run_server

I had to add management as a dependency to deploy inside modules.def.yml in order to get around a noclassdef found error at runtime. I believe this is os independant bug.

I have the following questions:
*) How to I create a package similar to the generic binary package you guys deliver?
*) At a high level, what is the boot JAR, is it os or jvm dependant, and is it used or required by the terracotta client and/or terracotta dso server?
*) is looks like libsigar is a dependancy, is this an optional dependancy? If so what are the benifits of having libsigar?

1) run "tcbuild dist" will create a package under "build/dist". Run "tcbuild help" for more info

2) Bootjar contains instrumented classes that are loaded by the VM during startup. It's os and jdk dependant but generated automatically for you if you use script bin/dso-java.sh or manually call bin/make-boot-jar.sh. Only clients need it.

3) libsigar is needed for status recording for profiling purpose. It's used by the admin console to capture CPU, Heap usage and other info. It's optional.

Thanks for the help, I was barking up the wrong tree, and you steered me in the right direction. I'm in the process of creating a port for FreeBSD. I wanted to ask about a couple of fields.

MASTER_SITES= http://s3.amazonaws.com/TCreleases/
MAINTAINER= brian@experts-exchange.com
COMMENT= Terracotta distributed caching server/client for java

I thought you might have more than more master site or a different master site in mind. When installing the port source will be automatically downloaded for them. I've also seen port, where for legal reasons the user is directed to download the file from a specific site, where they usually have to agree to a user agreement. I also though you might want to be co-listed as the maintainer of this port, or perhaps we create a mailing list that acts as the port maininter as well.

If you guys could care less, that is fine, I just thought that I would ask.

As we seem to be first company using this on FreeBSD, this scares us a bit. I was curious if you would be able to share your load testing implementation that use to the stability of releases across all the OS's you support, so that we could implement this on a couple of machines in house. This way we can start building some confidence in terracotta on FreeBSD.

I also getting involved in the java for bsd community, so I could see myself as a great resouce to you guys, for troubleshooting FreeBSD issues.

I've posted a few patches to the jira ticket for parts of this.

I'm seeing a lot of test failures related to:
junit.framework.AssertionFailedError: Exception in constructor: test (java.lang.AssertionError: No support for this OS: FreeBSD
at com.tc.net.EphemeralPorts.findRange(EphemeralPorts.java:41)

This seems to be because we don't match any of the if statements, but I now can't find the Os class, it seems to have been deleted, but yet is still being used in the tests?

I was simple going to change the Mac private class to 'Bsd' and add isBSD to Os, since both Mac and *BSD present this information through the same sysctls.

Actually trying to solve using Ehcache with Terracotta with the following error:
Code:

2010-07-20 11:29:11,435 [main] FATAL com.tc.object.bytecode.hook.impl.DSOContextImpl - Exception thrown
 org.osgi.framework.BundleException: Unknown or unsupported OS detected: FreeBSD
         at com.tc.plugins.ModulesLoader.getConfigPath(ModulesLoader.java:374)
         at com.tc.plugins.ModulesLoader.loadConfiguration(ModulesLoader.java:399)
         at com.tc.plugins.ModulesLoader.access$300(ModulesLoader.java:75)
         at com.tc.plugins.ModulesLoader$2.callback(ModulesLoader.java:206)
         at com.tc.bundles.KnopflerfishOSGi.startBundle(KnopflerfishOSGi.java:100)
         at com.tc.bundles.KnopflerfishOSGi.startBundles(KnopflerfishOSGi.java:73)
         at com.tc.plugins.ModulesLoader.initModules(ModulesLoader.java:211)
         at com.tc.plugins.ModulesLoader.initModules(ModulesLoader.java:128)
         at com.tc.object.bytecode.hook.impl.DSOContextImpl.<init>(DSOContextImpl.java:171)
         at com.tc.object.bytecode.hook.impl.DSOContextImpl.createContext(DSOContextImpl.java:156)
         at com.tc.object.bytecode.hook.impl.DSOContextImpl.createStandaloneContext(DSOContextImpl.java:141)
         at net.sf.ehcache.terracotta.StandaloneL1Boot.call(StandaloneL1Boot.java:221)
         at net.sf.ehcache.terracotta.StandaloneL1Boot.call(StandaloneL1Boot.java:40)
         at net.sf.ehcache.terracotta.StandaloneTerracottaClusteredInstanceFactory.<init>(StandaloneTerracottaClusteredInstanceFactory.java:137)
         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
         at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
         at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
         at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
         at net.sf.ehcache.util.ClassLoaderUtil.createNewInstance(ClassLoaderUtil.java:92)
         at net.sf.ehcache.TerracottaClusteredInstanceHelper.newClusteredInstanceFactory(TerracottaClusteredInstanceHelper.java:103)
         at net.sf.ehcache.CacheManager.init(CacheManager.java:306)
         at net.sf.ehcache.CacheManager.<init>(CacheManager.java:280)
         at cn.v2.research.terracotta.EhcacheTest.main(EhcacheTest.java:21)

Anyone got any pointers?