• New Feature
  • Status: Resolved
  • 2 Major
  • Resolution: Won't Fix
  • Build & Test
  • interfaces
  • Reporter: wharley
  • August 26, 2008
  • 0
  • Watchers: 1
  • February 12, 2014
  • February 12, 2014

Description

Terracotta is, in general, designed to work without changes to user code. However, it is often nice in test cases, problem repro cases, and the like, to be able to make sure that the Terracotta instrumentation is actually working as desired. This can help save some time in support and testing situations.

The following code snippet will do this, without requiring tc.jar to be on the compile or runtime classpaths:

public static void verifyTCInstrumentation() { Method[] methods = HashMap.class.getMethods(); boolean found = false; for (int i = 0; i < methods.length; ++i) { if (“__tc_managed”.equals(methods[i].getName())) { found = true; break; } } if (!found) { StringBuffer msg = new StringBuffer(); msg.append(“The DSO boot jar is not prepended to your bootclasspath! “); msg.append(“Generate it using the make-boot-jar script “); msg.append(“and place the generated jar file in the bootclasspath “); msg.append(“(i.e. -Xbootclasspath/p:/path/to/terracotta/lib/dso-boot/dso-boot-xxx.jar)”); System.err.println(msg.toString()); throw new Error(msg.toString()); } else { System.out.println(“Terracotta instrumentation is present.”); } }

It might be nice to package this up in some way (I’m not sure how), so that it can be easily reused.

Comments

Taylor Gautier 2008-08-27

great idea - tim-tclib is a good place for something like that (in the util package)

Chris Dennis 2009-02-24

Currently we have a tc property (tc.active) that is set by the ClassProcessorHelper after the client is initialized. This property being set not only asserts that the boot jar is present, but also that the client successfully connected to a server, and that dynamic instrumentation of user classes is now enabled. I think this is probably sufficient - but we could certainly make the initialization process test do more sanity checking as well - possibly configurable via a system property (-Dcom.tc.l1.sanitycheck=true).

Hung Huynh 2014-02-12

DSO is discontinued