Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Thanks-

Are the toolkit APIs available in the open source download of TC?

Ok, I've been away from TC for a while, last used it at version 3.1 or something, when I was doing plain DSO (using the annotations), and the "toolkit" API was new. I never got around to moving my code from the annotation-based DSO to the toolkit APIs.

So now, I need to possibly use TC again... but now I'm not sure what version to use or how to use it. Using simple APIs for sharing objects in a cluster seems the easiest - again, my use case is not just "database offloading" or caching or "big memory". I want "clustering" with fine-grained control over what is clustered and how.

So... someone point me in the right direction. Is DSO still at the heart of TC? Is the toolkit API still available for me to use to create shared objects in a cluster? In the old days, the amount of "network attached memory" was limited only by the disk available to my TC servers... is that still true?

I tried adding the TC repo (http://www.terracotta.org/download/reflector/maven2) to my Nexus repositories. It seems to download/build the indexes correctly, but isn't able to browse the remote (the TC repo) and I'm not getting the artifacts down to my local.

When I browse to the repo in my browser directly, I get a weird page - with a roller graphic and a "PWD:" prompt. This requires some authentication? What do I need to do here?

Thanks.

Shouldn't the TIM be doing that already? It's the SynchronizedList which is calling LinkedList.add().

I have a class that is shared in the cluster. This class contains a list which I need to apply synchronization to for it to work in the cluster.

So I tried:
Code:

 private List<Thing> things = Collections.synchronizedList(new LinkedList<Thing>());

but I still get a USOE on LinkedList.add().

I tried adding tim-synchronizedcollection (2.6.0) to my modules, and that didn't help.

I'm running 3.1.1.

Any clues?

I have a class that looks like this:

Code:

 public class Outer
 {
     @InstrumentedClass
     static class Inner
     {
     }
 
     @Root
     private Inner someRoot;
 
     private String someMemberVar;  
 
     public someMethod(String param)
     {
         someMemberVar = param;
     }
 }

Now, class Outer is not instrumented, either by annotation or by configuration. However, an instance of Outer is showing up in the shared object graph of another class entirely, and that code is calling Outer.someMethod, which is throwing a UnlockedSharedObjectException when trying to set someMemberVar.

So my question is... how is this happening when Outer is not even instrumented???

I have built a nice pub/sub system within a TC cluster using LBQs, and it works very well. My queues, however, are destructive-read only - i.e., the first consumer to get an event from the queue is the one that processes it, and no other.

If you are wanting delivery of the message to multiple subscribers where each subscriber gets a copy of the message you can also use queues but you'll have to write extra code to make sure you don't destroy messages on the queue. You'll also have to clean messages from the queue by some mechanism (timer, api, etc.). I don't think tim-messaging has support for this model.

Good luck!

I know I've seen it somewhere in the website a while back, but I can't find it now (and it's not mentioned on http://www.terracotta.org/confluence/display/docs31/DSO+Data+Structures+Guide) ... what's the best replacement for CSM?

I'm on TC 3.1 FX, using tim-concurrent-collections 1.2.2.

Sounds good to me - I'm checking with the powers-that-be to make sure they don't mind. I'll let you know via email or PM, and we can set up a call/webex.

Good news - I went ahead and tried this approach.

I'm using Javassist to instrument field access to the collections in which I want to automatically manage objects which are going into and out of, sending those objects to the SOR.

My instrumentation creates a handler for the collection and inserts it into the class which contains the collection (that class being a tc root). Field access to the original collection is diverted to the handler, which returns a proxy for the collection. When the code using the collection (or the proxy in this case) adds/removes from the collection, the proxy does SOR things and then passes the add/remove on to the delegate.

I've run this under TC 3.0.0 and it seems to work fine.

One thing I noticed in the developer's console is that wtihin my proxy object (which contains the delegate object) there is another delegate put there by TC (__delegate_tc_java_util_HashMap)), which makes me assume that TC is doing something similar to what I'm doing.

I don't know yet if put/get will work - I haven't implemented the locking yet (it works outside of TC; no locking).

Well, I'm having to revisit this now because I have to implement our SOR. I'm using TC 3.0.0 (about to go to 3.0.1), and tim-async for the persisting.

I've decided that I want to approach the issue this way:

Code:

 public class SomeClass
 {
     static class RootClass
     {
         @SORData
         public HashMap<String, SomeOtherClass> data = new ....
     }
 
     @Root
     public RootClass rootData = new RootClass();
 }

Now, I already have my own classloader which has the ability to do anything based on (or to) the classes it loads - I currently use it to generate code based on my own annotations at class load time. So I want to now have a way to trap calls to the annotated collection, such as add(), remove(), etc. and send the updates to my code which uses tim-async to persist the data.

My thought at the moment is to do this when I load the class I will create a dynamic proxy (using something like CGLIB or Javassist proxys) which I substitute in place of the collection. I think I can use Javassist or CGLIB to have the proxy created at runtime instead of the actual collection, and the proxy will create and delegate to the actual collection, sending updates to the SOR handler. Here's some almost-code showing what I would have after loading/modifying the classes:

Code:

 public class SomeClass
 {
     static class RootClass
     {
         private HashMap<String, SomeOtherClass> data_delegate = new ....		// field renamed
         public MyHashMapProxy data ....   // this would pass through calls to data_delegate
     }
 
     @Root
     public RootClass rootData = new RootClass();
 }

I think this will work just fine... outside of a TC environment :) I'm not sure how it could work within a TC environment due to TC's own instrumentation.

Any suggestions on this approach?

Can I have something like this:

Code:

 class X
 {
     static class ACContainer
     {
         AsyncCoordinator<SomeClass> ac1;
         AsyncCoordinator<AnotherClass> ac2;
     }
 
     @Root
     private ACContainer allACs = new ACContainer();
 }

Is this as good as having the AsyncCoordinators being individual Roots?

There is no cluster supported mechanism which does what you want.

This is a classic case of "request-reply over asynchronous messaging", where you are basically trying to call a service synchronously where the service is invoked and responds using async messages.

Two solutions come to mind:

1. Break your function "A" into two functions at the point of the call, or
2. Create a proxy within your system which you can call synchronously, and it handles the async nature of the communications with the service.

Solution 1 is easier to implement. Break A into A1 and A2. A1 does stuff, saves state in TC shared memory (keyed by some value), and calls the external service. When the external service responds, it is dispatched to A2. The response must have some value within it that you use to find the saved data from A1.

Solution 2 is basically the same thing, but you move the correlation into another class, and you have to manage the multiplexing between threads, etc.

So this is really not the type of problem TC was designed to directly solve (although the shared data helps).

If the state data within the service is clustered, then you have in effect shared state between service instances. So, it wouldn't matter which service instance handled the response message because it would have access to the same state data of the requesting instance. You'll need some kind of correlation value in the response to match it to the state data for the request.

So, change how you think about this from "looking up the requesting service instance" to "service instances sharing state data".

Hope that helps!

If the service class is not instrumented, then TC doesn't know about it, and it can't be put into a shared object graph. So, you can't store the reference to the service within your clustered object (unless it is in a transient variable).

Also, you can't reference objects from one JVM in a cluster that live on another JVM in a cluster as discrete instances. The objects are not shared across the nodes.

Can you give more info on what you're trying to do?