Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Hi kumars,

Please take a look at

http://www.terracottatech.com/forums/posts/list/79.page

It describes how what you are describing would work. Essentially, the answer to loading the context at runtime is yes, but there are some caveats.

With regards to load balancing, out of the box, Terracotta does not do load balancing per se. However, we open-sourced a grid using Terracotta that can easily be implemented in Spring and designed to do load balancing -- by which in this scenario, I would mean parition the processing logically so each node has a roughly equivalent amount of work to do. The grid and other tutorials are located at:

http://www.terracottatech.com/tutorials.shtml

Regards,

Gordon

Hi Sateesh,

It actually depends how you have coded the context loading. For instance, if your code looked something like this

new ClassPathXmlApplicationContext({ "config/foo.xml",
"config/bar.xml" });

and your config looked something like:

<paths>
<path>config/foo.xml</path>
<path>config/bar.xml</path>
</paths>

or this

<paths>
<path>*</path>
</paths>

that code should work. However, paths in the config are used for matching
only, but the name for the implicit context root in DSO is derived from the actual resource names. So, if you used the second configuartion, and you were to load those same contexts again, but use foo2.xml and bar2.xml, you will have two distinct DSO roots and beans won't be shared between these two contexts.

Also, as the call stack is used to calcuate the root name, you can only see that two app contexts are clustered if that new ClassPathXmlApplicationContext(..) call happens in the same call stack.

I would suggest loading the Spring contexts on init, store in them some kind of map, and then retrieve specific context instance using a key from their messages. Is this workable in your application?

Regards,

Gordon

Hi jfcloutier,

I was going back through the forums, and I see I answered this question in another post -- but that's not obvious. So just to add it here, our future support for annotations fortunately refers to DSO-specific annotations. DSO should not (and has not in our testing) break or interfere with non-DSO annotations in the instrumented bytecode.

Regards,

Gordon

Hi psripathi,

DSO does not rewrite or replace any of the JVM -- DSO uses byte-code weaving to work with Java as classes are loaded and fields modified, etc. Byte-code weaving is used extensively in the Java space.

Regards,

Gordon

Hi mayj,

I am not aware of any issues and I don't see where any would arise. However, I will continue to investigate and follow-up with additional information.

Regards,

Gordon

Michael,

We do not officially support Spring 2.0. I know of individuals who have successfully clustered Spring 2.0 applications using our product for Spring 1.2.8, but we can't guarantee compatibility.

Regards,

Gordon

Hi mouadbox,

This is informational output and is normal. With respect to seeing it twice -- we just use Spring's logging -- I'm not sure why it would appear twice. I'll see if I can reproduce the behavior. Could you also please check to be sure it appeared twice within the same run of the application?

Regards,

Gordon

Thanks!

Regards,

Gordon

Hi f00bar,

I like the handle, by the way. Without going into too much detail regarding future product direction, which I can't as this is a public forum, I can say several customers have asked us how they could use our disk-backed clustered POJOs as a kind of object database. We are looking at several alternatives as to how we might do this.

However, a doable solution today is simply to make multiple references to an object in more than one collection, using the values of different fields for keys -- or for instance, mix collection types -- use a linked list for sequential access to a set of objects and a map for key-based access. If those collections are shared using Terracotta, you can easily access the appropriate collection for the desired member whether at the moment you have a reference to that object or not. Terracotta is intelligent about how it loads collections into a client VM. Since they can be arbitrarily large and deep, using a map as an example, Terracotta only loads the key and the top level of the value (the depth to which the graph of the value is loaded is configurable). So in reality, you can keep a very, very large collection "in memory", iterating over the keys and referencing members of the collection only as needed. The Terracotta client faults those in only when you access them (and by the way can silently release memory used by shared objects w/o affecting the application in order to optimize memory use on the client).

Regards,

Gordon

Please note that as of version 2.1.3 of Terracotta DSO, Sessions and Spring, ConcurrentHashMap and FutureTask have been added to the list of supported classes.

You can download the latest version at:

http://www.terracottatech.com/downloads.jsp

Gordon

Hi Jean-Francois,

The answer is yes, it should it work fine -- all of our testing with this use case has shown that. The key point is to use AspectJ at compile time if aspects have any state that should be clustered.

The issue with AspectJ weaving at load time (LTW) and DSO is that DSO instrumentation runs before (as AspectJ uses javaagent and DSO is in the bootjar), meaning that any load time woven-in code won't be instrumented by DSO and hence, won't be clustered.

On the other hand, it is still possible to move all the clusterable state outside of aspects in a Spring application (i.e. inject it using Spring's @Configurable) and then we can cluster that data as usual. However, this works only for Spring and requires the Terracotta for Spring product. There is a good reference at http://static.springframework.org/spring/docs/2.0.x/reference/aop.html#aop-aj-configure.

Regards,

Gordon

Hi Jean-Francois,

Our future support for annotations fortunately refers to DSO-specific annotations. DSO should not (and has not in our testing) break or interfere with non-DSO annotations in the instrumented bytecode.

As far as using AspectJ, you should just have to just compile aspects as usual and add aspectjrt.jar to your application -- it shouldn't be different from running without DSO. When using load time weaving (LTW) with AspectJ, we have experimented with adding javaagent:<path to>/aspectjweaver.jar to the params of java command (along with the standard DSO bootclasspath param), and it has worked well. One thought -- AspectJ LTW is happening after DSO, so AspectJ wouldn't be able to reweave its advices.

Regards,

Gordon

Ulsa,

As you've seen, there's a known "bug" related to having the "wrong" tc.jar, which must be consistent across Terracotta components. Re-install ing Terracotta for Spring in your case should solve this and did.

Regards,

Gordon

Hi jfcloutier,

It sounds as though you would benefit from knowing about DSO's persistent mode feature. In persistent mode, the server permanently writes object state to disk.

As the reference version of the configuration file describes it, "'permanent-store' causes the DSO server to write data immediately and permanently to disk. Upon server restart, data will be restored, meaning data underneath roots in your program will be restored to the exact state it was in when the server shut down."

I believe this is exactly what you're looking for. I'll private message you my email address. However, feel free to post questions to the board as well, so others can benefit.

Regards,

Gordon

Hi jfcloutier,

We are in the process of testing that integration now. We have completed testing with compiled aspects and have moved on to testing runtime aspects. Barring any unexpected results, we anticipate officially supporting AspectJ-instrumented classes in a release somewhere between the end of the year and the very early part of next year.

Regards,

Gordon