[classlib][serialization] Conditional object replacement in ObjectInputStream - bug in RI?
Hi!
I've recently filed 2 JIRAs (HARMONY-1920 and HARMONY 1921) related to the
object replacement in ObjectInputStream by means of resolveObject() method
and during experimenting with the tests, created the test which replaces the
object according to some rule (see the code at the bottom of the message).
Unexpectedly it fails on RI with the output:
TestObjectInputStream.resolveClass() is called.
1-st read passed.
2-nd read failed with exception: java.lang.ClassCastException: b.TestClass
This output indicates that RI performs caching for object replacements and
second read just did not call resolveClass() method from
TestObjectInputStream.
I did not find any info about this case in serialization specification
and not quite sure if this behaviour is correct. Is this a bug in RI?
If not then this case should be also taken into account while fixing
HARMONY-1921 JIRA.
- Test.java -
import java.io.*;
public class Test {
public static void main(String[] args) throws Exception {
a.TestClass to1 = new a.TestClass();
to1.i = 555;
a.TestClass to2 = new a.TestClass();
to2.i = 777;
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(to1);
oos.writeObject(to2);
oos.flush();
byte[] bytes = baos.toByteArray();
ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
ObjectInputStream ois = new TestObjectInputStream(bais);
try {
b.TestClass to3 = (b.TestClass) ois.readObject();
if (to3.i != to1.i) {
System.out.println("1-st read failed. Expected: " + to1.i +
", got: " + to3.i);
} else {
System.out.println("1-st read passed.");
}
} catch (Exception ex) {
System.out.println("1-st read failed with exception: " + ex);
}
try {
a.TestClass to4 = (a.TestClass) ois.readObject();
if (to4.i != to2.i) {
System.out.println("2-nd read failed. Expected: " + to2.i +
", got: " + to4.i);
} else {
System.out.println("2-nd read passed.");
}
} catch (Exception ex) {
System.out.println("2-nd read failed with exception: " + ex);
}
}
static class TestObjectInputStream extends ObjectInputStream {
private boolean replaced = false;
public TestObjectInputStream(InputStream in) throws IOException {
super(in);
}
protected Class resolveClass(ObjectStreamClass desc)
throws IOException, ClassNotFoundException {
if (desc.getName().equals("a.TestClass")) {
System.out.println("TestObjectInputStream.resolveClass() is
called.");
if (!replaced) {
replaced = true;
return b.TestClass.class;
} else {
return a.TestClass.class;
}
}
return super.resolveClass(desc);
}
}
}
- a/TestClass.java -
package a;
import java.io.Serializable;
public class TestClass implements Serializable {
private static final long serialVersionUID = 1L;
public int i = 0;
}
- b/TestClass.java -
package b;
import java.io.Serializable;
public class TestClass implements Serializable {
private static final long serialVersionUID = 11111L;
public int i = 0;
}
-
Mikhail Markov
Intell Middleware Products Division
Re: [general][DGC] Java Distributed Garbage Collection in RMI
Wow - true DGC is really a cool thing! And i agree with you that there is very few RMI DGC docs. If your need some details about Harmony rmi dgc implementation - feel free to ask. Regards, Mikhail On 8/24/06, FaeLLe <[EMAIL PROTECTED]> wrote: Yes I should have the implementation completed by October by which time I will produce performance testing statistics and code to the community. At the moment the highly undocumented nature of the Java RMI dgc interfaces is proving to be a stumbling point hence I have turned to the Harmony mailing list for expertise. Regards, - Vikram Mohan On 8/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > Vikram, > I believe the right place to look for MMTk is on the JikesRVM web page > at jikesrvm.sourceforge.net. MMTk contains a bunch of different > garbage collectors and is written in Java. Its interesting what you > are discovering in distributed GC. Do you plan to do an Apache open > source version of the correct algorithm? :) > > > On 8/23/06, FaeLLe <[EMAIL PROTECTED]> wrote: > > Hello Weldon, > > > > I am currently working on the DGC interface on a Java level so that it > can > > work on top of the JVM. My modification is entirely is on the Java > level. > > > > What I am working on the implementeation of a Distributed Reference > Listing > > algorithm for RMI DGC. We have identified faults in the algorithm Sun > > currently uses and have explained them in the paper I mentioned before. > It > > is called a revised version of Birrell's algorithm. > > > > Not currently worked with MMTk but perhaps you can point me towards the > > project page of the toolkit you are describing. I have only heard about > it > > before not exactly ventured into it. > > > > Regards, > > > > - Vikram Mohan > > > > On 8/23/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > > > > > On 8/22/06, FaeLLe <[EMAIL PROTECTED]> wrote: > > > > Forwarding message to Harmony list as it was rejected previously as > spam > > > > probably due to ZIP attachement and links in body. > > > > > > > > From: FaeLLe [mailto:[EMAIL PROTECTED] > > > > > Sent: Tuesday, July 25, 2006 2:27 PM > > > > > To: Morozova, Nadezhda > > > > > Subject: Java Garbage Collection > > > > > > > > > > I obtained your email address from the Harmony mailing lists and > > > noticed > > > > the document you released on the Harmony mailing list about plugging > in > > > a > > > > custom GC implementation. > > > > > > > > > > The reason I am writing to you is that at the moment I am > undergoing > > > my > > > > Msc project at the University of Kent with my supervisor being Dr. > > > Richard > > > > Jones and am working on an implementation of Birrell's distributed > > > reference > > > > listing algorithm. > > > > > > > > > > We have worked on a formalization of the algorithm (TOPLAS paper ) > and > > > my > > > > task is the implementation of it. > > > > > > > > > > But I am confused as to what approach I would undertake towards > the > > > > implementation as to what part of the current Java code holds the > > > current > > > > algorithm etc. Is there any paper or resource you could point me to > for > > > > garbage collector implementation. > > > > > > > > > > Your document talks about implementing a GC written in C but I was > > > > wondering would it not be possible for me to merely edit the JDK > source > > > code > > > > under the JRL license for academic purposes and rewrite my own code > > > merely > > > > editing the method content. > > > > > > > > > > Your cooperation in this matter would be most appreciated. > > > > > > Vikram, > > > It would be great if you gave more details about what you are trying > > > to do. For example, do you need to modify the garbage collector that > > > is internal to a standard JVM? Or will all your work be at Java API > > > level? In terms of what is in DRLVM, the GC is written in C. I am > > > currently working on porting MMTk to DRLVM. Let me know if MMTk is > > > interesting to you. > > > > > > > > > > > > > Yours Sincierly, > > > > > > > > > > - Vikram Mohan > > > > > Msc. Distributed Systems and Networks > > > > > University of Kent > > > > > Canterbury, Kent > > > > > UK > > > > > +44-(0)77-37592552 > > > > > > > > > > > > > > > > > > > - > > > > Terms of use : > > > > http://incubator.apache.org/harmony/mailing.html > > > > To unsubscribe, e-mail: > > > > [EMAIL PROTECTED] > > > > For additional commands, e-mail: > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > -- > > > Weldon Washburn > > > Intel Middleware Products Division > > > > > > - > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > www.FaeLLe.com > > www.VikramMohan.com > > > > > > > -- > Weldon Was
Re: [general][DGC] Java Distributed Garbage Collection in RMI
[let's add prefix to the subject line]
Hi Vikram,
I've attached test.txt file containing all necessary java sources as well as test output on Harmony (actually, it's the same on RMI also).
Regards,
Mikhail
On 8/23/06, FaeLLe <[EMAIL PROTECTED]> wrote:
Hello Mikhail,Thanks for the reply !However your email only contained the attachement of the output do not see
the modified sources. If you could reply with them it would be nice.Thanks,- Vikram MohanOn 8/23/06, Mikhail Markov <[EMAIL PROTECTED]
> wrote:>> Hi Vikram,>> First of all, what rmi module are you using: rmi or rmi2? rmi module does> not support sun.* properties. Instead it supports a parallel structure of> harmony.* ones.
>> About your question about DGC (i'll use rmi module as an example):> Remote object (on server side!) could be collected if all the conditions> below are met:> 1) (Of course) no hard references in local VM
> 2) no remote references from from other VMs> 3) no in-progress remoted calls>> Here is one of the simplest test scenarious showing how to check these> conditions:>> - run rmi-registry in separate VM
> - export remote object, register it in the registry and remove hard> references to this object> - kill rmi-registry VM> - wait for a period of time longer than the one specified by "
> java.rmi.dgc.leaseValue" property (the default is 10 min)> - if remote object implements Unreferenced then it's unreferenced() method> should be called here> - run GC - the object should be collected and it's finalize() method
> should be called>> I think your code is doing a lot of extra staff so i've modified it to> implement this test scenarious (see attachment).> I did not use ProcessBuilder class as Harmony does not have it yet. The
> output of the test is also attached.>> Hope this helps.>> Regards, Mikhail> Intel MIddleware Products Division>>>> > > Been experimenting with the DGC interface of Java RMI and as far as I
> > have understood there is no way to make a remote object be garbage collected> > other than invoke System.gc() and let it be collected over time.> > >> > > I however notice that the internal calls can be tracked by setting the
> > following system properties,> > >> > > System.setProperty("java.rmi.server.logCalls", "true");> > > System.setProperty ("sun.rmi.dgc.logLevel
", "VERBOSE");> > > System.setProperty("sun.rmi.dgc.logCalls", "true");> > >> > > What I was wondering is if you had any suggestions on how to actually
> > ensure that the remote object has been collected. I tried placing> > System.out.println() statements in the finalize() and unreferenced()> > methods (the client also implements the Unreferenced interface) however it
> > seems to generate no such output.> > >> > > Neither do the internal rmi logs that should be displayed in output in> > verbose mode show any indication of this happening.
> > >> > > I have attached the code if you would be willing to examine it and let> > me know what I am not doing correctly. Ps. I have included them in zip> > format and as Java sources whichever is convinient for you.
> > >> > > TestDistributedGarbageCollection.java is the RMI server and the> > EchoClient.java is the RMI client.> > >> > > Regards,> > >> > > - Vikram Mohan
> >>> -> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]> For additional commands, e-mail:
[EMAIL PROTECTED]>>>--www.FaeLLe.comwww.VikramMohan.com
EchoInterface.java:
--
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface EchoInterface extends Remote {
public String echo(String msg) throws RemoteException;
}
--
EchoObject.java:
---
import java.rmi.Remote;
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
import java.rmi.server.Unreferenced;
public class EchoObject implements EchoInterface, Unreferenced {
public EchoObject() throws RemoteException {
UnicastRemoteObject.exportObject(this);
}
public String echo(String msg) throws RemoteException {
System.out.println(msg);
return this.getClass() + " - Have said: " + msg;
}
public void unreferenced() {
System.out.println("EchoObject unreferenced");
}
public void finalize() throws Throwable {
super.fin
Re: Java Distributed Garbage Collection in RMI
Hi Vikram,
First of all, what rmi module are you using: rmi or rmi2? rmi module does not support sun.* properties. Instead it supports a parallel structure of harmony.* ones.
About your question about DGC (i'll use rmi module as an example):
Remote object (on server side!) could be collected if all the conditions below are met:
1) (Of course) no hard references in local VM
2) no remote references from from other VMs
3) no in-progress remoted calls
Here is one of the simplest test scenarious showing how to check these conditions:
- run rmi-registry in separate VM
- export remote object, register it in the registry and remove hard references to this object
- kill rmi-registry VM
- wait for a period of time longer than the one specified by "java.rmi.dgc.leaseValue" property (the default is 10 min)
- if remote object implements Unreferenced then it's unreferenced() method should be called here
- run GC - the object should be collected and it's finalize() method should be called
I think your code is doing a lot of extra staff so i've modified it to implement this test scenarious (see attachment).
I did not use ProcessBuilder class as Harmony does not have it yet. The output of the test is also attached.
Hope this helps.
Regards, Mikhail
Intel MIddleware Products Division
> Been experimenting with the DGC interface of Java RMI and as far as I have understood there is no way to make a remote object be garbage collected other than invoke System.gc() and let it be collected over time.
> > I however notice that the internal calls can be tracked by setting the following system properties,> > System.setProperty("java.rmi.server.logCalls", "true");
> System.setProperty ("sun.rmi.dgc.logLevel", "VERBOSE");> System.setProperty("sun.rmi.dgc.logCalls", "true");> > What I was wondering is if you had any suggestions on how to actually ensure that the remote object has been collected. I tried placing
System.out.println() statements in the finalize() and unreferenced() methods (the client also implements the Unreferenced interface) however it seems to generate no such output.> > Neither do the internal rmi logs that should be displayed in output in verbose mode show any indication of this happening.
> > I have attached the code if you would be willing to examine it and let me know what I am not doing correctly. Ps. I have included them in zip format and as Java sources whichever is convinient for you.
> > TestDistributedGarbageCollection.java is the RMI server and the EchoClient.java is the RMI client.> > Regards,> > - Vikram Mohan
Test: ready
Test: VM2 destroyed
EchoObject unreferenced
Test: sleep finished
EchoObject finalized
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
