Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Hi Pavol. Thanks a lot for your very detailed feedback - it's extremely valuable to us. I think we have a good understanding the problem you're running into, and I agree that solving it only with a declarative, config-based mechanism could be problematic. We'll put our thinking caps on here and see if we can roll out a solution for this.

Cheers,
-p

_________________
Patrick Calahan
Director, Product Management
Terracotta, Inc.

Hi Tim, you are right I have several classloaders in my application and it contains also custom ObjectInputStream. Right now weI use only URLClassLoader, but it looks like we will need our own subclass of classloader soon, because extension we need to do does not look like it fits custom stream handler well.

I understand that it is necessary to distinguish between classloaders in order to support materialization of objects, but I cannot imagine how that could be achieved in API-less environment. Also pure configuration approach might not be very flexible. Thus I would probably go with approach similar to approach used in Spring framework - to define hook interface that is registered in DSO. That makes one class of application dependent on DSO, but that is OK, because whole new area of applicability of DSO occured.

Thanks,
Pavol

Hi Pavol,

First of all thank you for your interest in DSO and the complete test case (both are greatly appreciated!). Your particular use case (user defined class loaders) is not yet fully supported in our current release. The basic problem is that your classloader instance has no strong identity associated with it. Other loaders in the system (the system classloader, extensions loader, web app loaders) are readily identifiable can be located through standard methods.

Since you posted this test case, I’m assuming your application uses its own classloader(s) other than the system loader and/or those provided by a web container (ie. tomcat, weblogic, etc). DSO already correctly handles the more complicated classloader heirarchies in web containers, but as I mentioned before we don’t have a generic mechanism available in the current release.

The problem to solve is that somehow DSO needs to know how to locate your classloader(s) when materializing existing shared objects. This implies some sort of classloader registry where your loader(s) can be associated with a unique name. Does that make sense? How would you expect to interact with such an interface (external config, API, something else)? We already have a few prototypes for this feature, but I’d like to explore your expectations first.

Thanks,
Tim Eck – Terracotta

p.s. While we’re on the topic, if you wanted to serialize/deserialize instances of your StoredDataImpl class, I believe you would need to use a custom version ObjectInputStream that overrides the resolveClass() method to work with your loader(s). Otherwise, standard java serialization will attempt to resolve your class with the system loader and fail with a ClassNotFoundException

I have problem using DSO in my application containing several classloaders (objects managed by DSO are from those special classloaders).

One instance of application is able to send instances to server, however another instance of application cannot obtain them. ClassNotFoundException occurs as if client side of DSO tried to use classpath classloader for those classes.

I have prepared test case demonstrating this behavior. It can be downloaded here http://www.pb.bsoft.sk/dso/testcase.zip.
Apart from sources, it contains 2 prepackaged JAR files one for each classloader and batch file for execution. Run it once and then for the 2nd time while the 1st is stil running. ClassNotFoundException is shown there.

Is it possible to solve this problem somehow?

Thank you for your answer,
Pavol

Re: DSO not working at all?
Posted: Jul 7, 2005 8:02 PM in response to: tor Reply

Thanks for the feedback.

We are aware of the docs issue and it will be corrected in the first dot release (probably tomorrow). The release will include improved docs as well as a few bug fixes. A tutorial is also in the works and should be out soon.

Cheers,
Steve

Re: DSO not working at all?
Posted: Jul 7, 2005 5:37 PM in response to: tor Reply

Well, sorry to tell you but your documentation is hard to find and IMHO not very well written. I would expect to find the documentation in the docs directory and not hidden as a tiny link in the readme file...

And yes, my expectation was that all invocations of the put method would be locked. To be honest, I didn't find the documentation before you wrote about it and I realized that there even existed a documentation somewhere. I'll try to find time to read through the docs before making more attempts on using the software. Until now I was just working with a copy&paste version of another demo project.

What about writing a kind of tutorial for Teracotta?

Tor

Re: DSO not working at all?
Posted: Jul 7, 2005 8:09 AM in response to: tor Reply

The problem here is that although you have defined a lock in your configuration, there effectively isn't any locking in your program. By design, DSO will not let you modify a shared object w/o locks. Let me clarify that a bit...

Based on the client side instrumentation logging you posted, your lock definition for test.Test.put(String, String) is set for "autolocks". DSO "autolocks" extend any synchronization present in your methods. If your put() method had synchronized on any objects, DSO would have included instrumentation to promote those synchronized statements to distributed locks (if and only if the object synchronized on was a DSO shared object).

To fix your example, I suggest changing the body of your put() method to:
synchronized(map) {
map.put(a, b);
}

In my opinion, adding this syncronization is a natural thing to do anyway. In a multi-threaded context (or multi-VM), it will prevent your map from being corrupted.

Out of curiousity, what was your expectation of the the lock you defined in your configuration? If you expected that a distributed lock would be placed around each invocation of put(), then you probably wanted a "named" lock (as opposed to autolocks). I can post more details about these different lock types, but that information is also available in the product documentation.

hope this helps

Re: DSO not working at all?
Posted: Jul 7, 2005 2:34 AM in response to: tor Reply

Ok, directly sharing all primitive wrapper instances is probably not a good usecase anyway. So, I extended my testcase to use a HashMap instead and changed my code into the following:

package test;
import java.util.HashMap;
public class Test {
private HashMap map = new HashMap();
public static void main(String[] args) {
new Test().put("foo", "bar");
}
public void put(String a, String b) {
map.put(a, b);
}
}

I also added a lock definition to my put method:

<method-expression>* test.Test.put(..)</method-expression>

When starting, the client also seem to recognize all instrumentation features I've configured:

2005-07-07 11:29:50,343 [main] INFO com.terracottatech.dso.instrumentation - DSO root inserted for field test.Test.map, type Ljava/util/HashMap;
2005-07-07 11:29:50,421 [main] INFO com.terracottatech.dso.instrumentation - Inserting autolocks in method test.Test.put(Ljava/lang/String;Ljava/lang/StringV, level: write
2005-07-07 11:29:50,421 [main] INFO com.terracottatech.dso.instrumentation - test.Test included for instrumentation

but still an exception is thrown claiming that I don't have a lock on the shared object:

Exception in thread "main" com.tc.object.tx.UnlockedSharedObjectException: main An attempt has been made to access a shared object without first getting a shared lock. Please specifiy a lock for this access via your terracotta-config.xml file.
at com.tc.object.tx.ClientTransactionManagerImpl.getTransaction(ClientTransactionManagerImpl.java:182)
at com.tc.object.tx.ClientTransactionManagerImpl.logicalInvoke(ClientTransactionManagerImpl.java:416)
at com.tc.object.TCObjectImpl.logicalInvoke(TCObjectImpl.java:326)
at com.tc.object.bytecode.ManagerImpl.logicalInvoke(ManagerImpl.java:319)
at com.tc.object.bytecode.ManagerUtil.logicalInvoke(ManagerUtil.java:152)
at java.util.HashMap.put(HashMap.java)
at test.Test.put(Test.java:12)
at test.Test.main(Test.java:8)

Tor

Re: DSO not working at all?
Posted: Jul 6, 2005 6:11 PM in response to: teck Reply

For reference, this is the relevant portion of the FAQ for version 1.1

- Can any object be a root?

Almost. In the current version of the product java.lang.Boolean, java.lang.Long, java.lang.Short, java.lang.Byte, java.lang.Integer, java.lang.Double, java.lang.Float, java.lang.Character, java.lang.String and java.util.Date cannot be roots. This limitation will be addressed in the next release. Any other instrumented Object can be a root.

Re: DSO not working at all?
Posted: Jul 6, 2005 5:14 PM in response to: tor Reply

Hi Tor,

Thank you for the detailed information. I believe the problem you're running into is a limitation in our first release here. In a nutshell, there is a very small set of classes that DSO treats as "literals". Instances of these "literal" classes cannot (currently) be used as DSO Roots. The complete list of classes can be found in the DSO Frequently Asked Questions (FAQ) document (dso-faq.txt) which should be in the top level directory of the Terracotta software you have downloaded.

Also, note that this limitation only applies for Root instances. You can certainly use instances of "literal" classes within the object graph underneath a Root. They just can't comprise the start of a distributed object graph. To be honest, instance of "literal" classes don't make for interesting Roots, but they should (and will) work in a future release.

To fix your example, your root field (test.Test.i) needs to be a different type (ie. not a "literal" type).

hope this helps, and thanks for trying out DSO!

Re: DSO not working at all?
Posted: Jul 6, 2005 4:29 PM in response to: tor Reply

Ok, rebuilding the dso-boot.jar made the demos work with Java 5 as well, but I'm still not able to get own code to work. I've implemented a very naive test case:

package test;
public class Test {
private Integer i;
public static void main(String[] args) {
new Test().i = new Integer(0);
}
}

Configuring test.Test.i to be part of an DSO client root causes the following exception to be thrown in the line where i is assigned a value:

Exception in thread "main" java.lang.ClassCastException: java.lang.Integer
at com.tc.object.applicator.PhysicalApplicator.dehydrate(PhysicalApplicator.java:84)
at com.tc.object.TCClassImpl.dehydrate(TCClassImpl.java:106)
at com.tc.object.TCObjectImpl.dehydrate(TCObjectImpl.java:286)
at com.tc.object.change.TCChangeBufferImpl.writeTo(TCChangeBufferImpl.java:55)
at com.tc.object.tx.TransactionBatchWriter.addTransaction(TransactionBatchWriter.java:79)
at com.tc.object.tx.RemoteTransactionManagerImpl.commit(RemoteTransactionManagerImpl.java:51)
at com.tc.object.tx.ClientTransactionManagerImpl.commit(ClientTransactionManagerImpl.java:213)
at com.tc.object.tx.ClientTransactionManagerImpl.commit(ClientTransactionManagerImpl.java:192)
at com.tc.object.bytecode.ManagerImpl.commit(ManagerImpl.java:77)
at com.tc.object.bytecode.ManagerUtil.commit(ManagerUtil.java:31)
at test.Test.__tc_seti(Test.java)
at test.Test.main(Test.java:8)

The client log ends with a warning:

2005-07-07 01:26:06,095 [main] WARN com.terracottatech.dso.runtime - java.lang.Integer is instrumented, but the following superclasses are not: (java.lang.Number). This can lead to unexpected behavior such as missing field changes or, if no default constructor exists, an exception

And the server log complains about the client disconnecting (probably because of the exception thrown):

2005-07-07 01:26:06,579 [TCComm Selector Thread 1 (listen 0.0.0.0:9510)] INFO com.tc.net.core.TCConnection - error reading from channel java.nio.channels.SocketChannel[connected local=/127.0.0.1:9510 remote=/127.0.0.1:3612]: Eine vorhandene Verbindung wurde vom Remotehost geschlossen
2005-07-07 01:26:06,579 [TCComm Selector Thread 1 (listen 0.0.0.0:9510)] INFO com.tc.net.core.TCConnectionManager - error event on connection com.tc.net.core.TCConnectionJDK14@32708178: connected: true, closed: false local=127.0.0.1:9510 remote=127.0.0.1:3612 connect=[Thu Jul 07 01:26:05 CEST 2005] idle=468ms: Eine vorhandene Verbindung wurde vom Remotehost geschlossen

The system is WinXP @ AMD64 and I have exactly the same behaviour both with the included JRE and with Sun's 1.5.0_01.

Tor

Re: DSO not working at all?
Posted: Jul 6, 2005 2:45 PM in response to: tor Reply

If you are using 1.5, then you will definately have to regenerate the dso-boot.jar file using the bin/dso-make-boot-jar script. You will also have to make sure it is in the boot classpath by either:
a) set the DSO_BOOT_JAR environment variable before calling the dso-java script, or
b) setting the -Xbootclaspath flag so that it uses the newly generated dso-boot.jar.

Re: DSO not working at all?
Posted: Jul 6, 2005 1:39 PM in response to: tor Reply

Hello,

DSO does not currently support 1.5 though others have tried it with some success. If you are trying to instrument java base classes that are not already pre-instrumented you need to do it in the boot-jar. It would also help us to know what platform and vm you are running on (It should all be in your terra.log file so just sending that would do the trick). send it to support@terracottatech.com.

Cheers,
Steve

DSO not working at all?
Posted: Jul 6, 2005 1:30 PM Reply

Hi,

finally Terracottatech managed to provide some sort of demo software after a lot of hype in the last few months, but even if the included demos are working, all my attempts to use DSOs in my own code is failing. Errors are varying between IncompatibleClassChangeErrors and ClassNotFoundExceptions or LinkageErrors when trying to use classes from the standard API library. Not to mention, that the whole stuff is not working with Java 5 at all...

Has someone been able to use this software?

Tor

Re: Converting JMS to Java
Posted: Aug 11, 2005 1:34 PM in response to: pcal Reply

Hi Bill,

Let me take a stab at answering your questions:

Persistant Destinations:
DSO uses a database on the L2 to persist objects to disk, so both the messages and the destinations can be persistent. The easiest way to build a messaging system using the Java APIs would be to share a java.util.List. There would be trade offs to this approach -- you wouldn't get some JMS features like TTL and message selectors, but you would get other features that JMS does not provide, such as object identity (pass-by-ref semantics across VMs), distributed wait/notify, and of course, a *much* simpler API.

Time To Live:
Using DSO in the 1.1 release, you would need to handle this at the app level, i.e. put a time-to-live as a field in the object, and have the application code filter expired messages. It might be possible to extend DSO to handle this automatically in a future release. We'd love to hear your requirements around this.

Message Durability and Durable Subscribers:
JMS pub/sub with durable subscribers can be modeled using a hashmap of queues, where the key is the subscriber id. For each published message, an object will be added to every queue. But note that it is not a separate copy of the object on each queue, but a reference to a single object, hence the overhead is low. This data structure could be combined with either distributed method call or wait/notify to notify clients when new messages (objects) are published.

Longer term, we've considered creating a transparency layer that would map java.util.List onto JMS, such that JMS would be used for the message transport. This might be useful for integrating with JMS-based systems while providing a simpler API, and for exploiting special features of different JMS implementations.'

In light of the functionality that DSO provides, you may also consider whether your application needs to be designed using a messaging paradigm. Using DSO, it is possible to design and develop for a single multi-threaded VM, with the knowledge that some of the objects will ultimately be shared. This allows you to focus on the application logic and data structures, without worrying about state distribution and clustering. You may find that it changes the way you approach building distributed systems in Java.

Hope this helps,

-Don Ferguson