Author |
Message |
05/24/2006 15:31:56
|
Admin
master
Joined: 05/24/2006 12:45:08
Messages: 71
Offline
|
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
|
|
|
05/24/2006 15:32:11
|
Admin
master
Joined: 05/24/2006 12:45:08
Messages: 71
Offline
|
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
|
|
|
05/24/2006 15:32:32
|
Admin
master
Joined: 05/24/2006 12:45:08
Messages: 71
Offline
|
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.
|
|
|
05/24/2006 15:32:49
|
Admin
master
Joined: 05/24/2006 12:45:08
Messages: 71
Offline
|
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
|
|
|
05/24/2006 15:33:11
|
Admin
master
Joined: 05/24/2006 12:45:08
Messages: 71
Offline
|
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!
|
|
|
05/24/2006 15:33:26
|
Admin
master
Joined: 05/24/2006 12:45:08
Messages: 71
Offline
|
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.
|
|
|
05/24/2006 15:33:47
|
Admin
master
Joined: 05/24/2006 12:45:08
Messages: 71
Offline
|
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
|
|
|
05/24/2006 15:34:07
|
Admin
master
Joined: 05/24/2006 12:45:08
Messages: 71
Offline
|
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
|
|
|
05/24/2006 15:34:23
|
Admin
master
Joined: 05/24/2006 12:45:08
Messages: 71
Offline
|
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
|
|
|
05/24/2006 15:34:42
|
Admin
master
Joined: 05/24/2006 12:45:08
Messages: 71
Offline
|
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
|
|
|
|