You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/02/16 12:19:09 UTC
[AltRMI] Two way weak hashmap for distributed garbage collection
Folks,
I have searched for, but cannot find, a posting in this mail list some
while ago that offered a "two way hashmap". We think we might be able
to use it for distributed garbage collection.
Background : AltRMI creates a clientside stub for each server side
facade reference in use. On the client side this is two hash maps. One
allowing lookup of instance based on reference key (a Long at the
moment), and one that allows the reverse lookup. I'd like to move to
some better design that will allow the client side garbage collector (I
am on about the one built into the JVM) to allow purges from the map.
Clearly we need to move to an impl based on Weak References and also to
an impl that is more efficient that to mutually pointing hashmaps.
Once that purging map were in place the clientside factory could
invisibly communicate back to the server which references were no longer
used by a session. Thus in some stuttering nature, the distributed
garbage collection works.
Does anyone know where that hash map impl is? Did it get combined into
commons-collections?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] Two way weak hashmap for distributed garbage collection
Posted by Paul Hammant <Pa...@yahoo.com>.
Juozas,
>I 99% sure RMI distributed GC implementation baset on "finalize()",
>
Not in 1.3.1 nor in 1.4 (I have checked). There are some 20 other uses
though.
This bug
http://developer.java.sun.com/developer/bugParade/bugs/4148454.html and
others show why finalize() is dodgy.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] Two way weak hashmap for distributed garbage collection
Posted by Juozas Baliuka <ba...@mwm.lt>.
I 99% sure RMI distributed GC implementation baset on "finalize()",
but I can implement some for client side today.
it can be this kind :
interface CleanupListener {
public vaid onCleanup( Object key );
// object must be mapped, because object will be invalidated before this
method call
}
// this class will call "onCleanup( Object key );" then object becomes
unreacheble
public class Queue {
Queue(CleanupListener listener){
................................................
}
void put(Object key, Object value){
.............................................
}
}
It can help to implement distributed GC, do you need this code ?
> Juozas,
>
> Thanks but I have had an on/off relationshp with finalize() from 1998
> onwards. Sun even give advice on why it should not be used.
>
> It is a WeakReference soltution I am looing for.
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] Two way weak hashmap for distributed garbage collection
Posted by Juozas Baliuka <ba...@mwm.lt>.
----- Original Message -----
From: "Paul Hammant" <Pa...@yahoo.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, February 16, 2002 2:21 PM
Subject: Re: [AltRMI] Two way weak hashmap for distributed garbage
collection
> Juozas,
>
> Thanks but I have had an on/off relationshp with finalize() from 1998
> onwards. Sun even give advice on why it should not be used.
>
> It is a WeakReference soltution I am looing for.
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
Re: [AltRMI] Event Notifier
Posted by vinaysahil chandran <sa...@yahoo.com>.
>
> There was also that (LGPL) project at sourceforge
> that could multiplex
> any traffic over one connection.
I guess BEEP protocol also address multiplexing
over single TCP socket connection.
http://www.beepcore.org
Again there is a LGPL java beep library at sourceforge
.
http://sourceforge.net/projects/beepcore-java/
????
V i n a y
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] Event Notifier
Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,
>Anyways on another page , I feel it would be good
>exercise to have the Event Notifier pattern working
>over AltRMI transport,
>something along the lines of the same pattern
>over RMI .(ref
>http://www.javareport.com/html/from_pages/oldarticles.asp?ArticleID=132
>
>)
>
>This would neccessiate a form of callbacks to be
>made avaliable within the Altrmi realm.
>Maybe by keeping a Message-Loop Thread at the
>client-end Open for receipt of REQUEST messages back
>from the server.
>Essentially implying REQUEST messages can flow
>from the server to the client too :-)
>
Yup this would be cool. The problem as I see is that we would have to
have a second connection open. I am sure smarter people could get
duplex working over one connection usine notify/wait etc, but I can't
see the solution without two connections (one for the server to listen
on and one for the client to listen on).
Does anyone have any experience on duplex over one socket connection?
There was also that (LGPL) project at sourceforge that could multiplex
any traffic over one connection. It was very good in that it could
shove data before it was even picked up at the other end. Not so
relevent to us as we have multiple transports types...
>This can again form one those so called (non-junit)
>*test* cases which actually does more than *testing*.
>
He he.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[AltRMI] Event Notifier
Posted by vinaysahil chandran <sa...@yahoo.com>.
Hi,
> Sorry dude, I turned the bat files into ant targets
> :
>
> ant -buildfile tests2.xml procon-serve
> ant -buildfile tests2.xml procon-client
Dont be sorry ! .
I should be .
Ant targets are more a consistent means to work with.
Anyways on another page , I feel it would be good
exercise to have the Event Notifier pattern working
over AltRMI transport,
something along the lines of the same pattern
over RMI .(ref
http://www.javareport.com/html/from_pages/oldarticles.asp?ArticleID=132
)
This would neccessiate a form of callbacks to be
made avaliable within the Altrmi realm.
Maybe by keeping a Message-Loop Thread at the
client-end Open for receipt of REQUEST messages back
from the server.
Essentially implying REQUEST messages can flow
from the server to the client too :-)
This can again form one those so called (non-junit)
*test* cases which actually does more than *testing*.
Regards,
V i n a y
--- Paul Hammant <Pa...@yahoo.com> wrote:
> Vinay,
>
> >Paul,
> >
> >>This submitted too. Thanks.
> >>
> >welcome..
> >So what would be the right way to
> >make the Provider-Consumer example run?
> >
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] Passing stubs around
Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,
>Paul,
>
>>This submitted too. Thanks.
>>
>welcome..
>So what would be the right way to
>make the Provider-Consumer example run?
>
Sorry dude, I turned the bat files into ant targets :
ant -buildfile tests2.xml procon-serve
ant -buildfile tests2.xml procon-client
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] Passing stubs around
Posted by vinaysahil chandran <sa...@yahoo.com>.
Paul,
> This submitted too. Thanks.
welcome..
So what would be the right way to
make the Provider-Consumer example run?
V i n a y.
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] Passing stubs around
Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,
This submitted too. Thanks.
- Paul
>Hi,
>The client stubs should be capable
>of being passed around as an argument(s)..
>a simple program to give the stub
>one got from the server back to it is attached
>herewith,
>One would hope that it would resolve on the server ,
>to the impl registered with it....
>What would be right way to acheive the same .?
>
>One way I found was working with making all
>proxies as (AltrmiProxy ) being serializable.
>(java.rmi.server.RemoteObject is serializable for
>this cause)
>Maybe DefaultMethodHandler during its correctArgs(..)
>call will replace the stub with remote impl registered
>
>with server.
>makes sense .
>
>V i n a y
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Sports - Coverage of the 2002 Olympic Games
>http://sports.yahoo.com
>
>
>------------------------------------------------------------------------
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] ALTRMI ClassLoaderInputStream
Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,
>Hi,
>Patch to enable the ObjectInputStream a chance to
>use its resolveClass(..) to load classes .
>
Applied - thanks :-)
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[PATCH] ALTRMI ClassLoaderInputStream
Posted by vinaysahil chandran <sa...@yahoo.com>.
Hi,
Patch to enable the ObjectInputStream a chance to
use its resolveClass(..) to load classes .
V i n a y
Index: ClassLoaderObjectInputStream.java
===================================================================
RCS file:
/home/cvspublic/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/common/ClassLoaderObjectInputStream.java,v
retrieving revision 1.1
diff -r1.1 ClassLoaderObjectInputStream.java
40c40,43
< final Class clazz =
---
> Class clazz =null;
> try
> {
> clazz =
42c45,50
<
---
> }
> catch(ClassNotFoundException cnfe)
> {
> }
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] Passing stubs around
Posted by vinaysahil chandran <sa...@yahoo.com>.
Another option would be to use
Annotations;
annotateClass(..) overrides in our
ClassLoaderObjectOutputStream(todo)
to pass the extra class information which
ClassLoaderObjectInputStream can use to dynamically
load new classes ....
Have not given much thought on the way we
can achieve the same & the repercussions it might have
, but I guess this would be a much cleaner way .
comments????
V i n a y
--- vinaysahil chandran <sa...@yahoo.com> wrote:
> Hi,
> The client stubs should be capable
> of being passed around as an argument(s)..
> a simple program to give the stub
> one got from the server back to it is attached
> herewith,
> One would hope that it would resolve on the server ,
> to the impl registered with it....
> What would be right way to acheive the same .?
>
> One way I found was working with making all
> proxies as (AltrmiProxy ) being serializable.
> (java.rmi.server.RemoteObject is serializable for
> this cause)
> Maybe DefaultMethodHandler during its
> correctArgs(..)
> call will replace the stub with remote impl
> registered
>
> with server.
> makes sense .
>
> V i n a y
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Sports - Coverage of the 2002 Olympic Games
> http://sports.yahoo.com
> ATTACHMENT part 2 application/x-zip-compressed
name=more_tests_with_altrmi.zip
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[AltRMI] Passing stubs around
Posted by vinaysahil chandran <sa...@yahoo.com>.
Hi,
The client stubs should be capable
of being passed around as an argument(s)..
a simple program to give the stub
one got from the server back to it is attached
herewith,
One would hope that it would resolve on the server ,
to the impl registered with it....
What would be right way to acheive the same .?
One way I found was working with making all
proxies as (AltrmiProxy ) being serializable.
(java.rmi.server.RemoteObject is serializable for
this cause)
Maybe DefaultMethodHandler during its correctArgs(..)
call will replace the stub with remote impl registered
with server.
makes sense .
V i n a y
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
RE: [AltRMI] Two way weak hashmap for distributed garbage collection
Posted by Gerhard Froehlich <g-...@gmx.de>.
>-----Original Message-----
>From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>Sent: Saturday, February 16, 2002 2:22 PM
>To: Jakarta Commons Developers List
>Subject: Re: [AltRMI] Two way weak hashmap for distributed garbage
>collection
>
>
>Juozas,
>
>Thanks but I have had an on/off relationshp with finalize() from 1998
>onwards. Sun even give advice on why it should not be used.
>
>It is a WeakReference soltution I am looing for.
Just throw a look into:
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simple
store/cache/impl/SoftRefMemoryCache.java
that's based on weak references...
~Gerhard
"When I die, I want to go just like my Grandfather,
in my sleep.
Not like the screaming passengers in the car
he was driving."
(Ancient Chinese Proverb)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] Two way weak hashmap for distributed garbage collection
Posted by Paul Hammant <Pa...@yahoo.com>.
Juozas,
Thanks but I have had an on/off relationshp with finalize() from 1998
onwards. Sun even give advice on why it should not be used.
It is a WeakReference soltution I am looing for.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] Two way weak hashmap for distributed garbage collection
Posted by Juozas Baliuka <ba...@mwm.lt>.
Hi,
It some implementation in simplestore "Cashe", but it is not useful for
distributed GC.
I think there is more trivial way to implement ditributed GC.
1. Client creates Object, server adds reference
SomeSubConstructor(Server server ){ // internal implementation calls this
server.addReference(); ++
}
2. protected void finalize() // GC calls this
throws Throwable{
server.release() ; --
}
this will work without java.lang.ref.* ;
> Folks,
>
> I have searched for, but cannot find, a posting in this mail list some
> while ago that offered a "two way hashmap". We think we might be able
> to use it for distributed garbage collection.
>
> Background : AltRMI creates a clientside stub for each server side
> facade reference in use. On the client side this is two hash maps. One
> allowing lookup of instance based on reference key (a Long at the
> moment), and one that allows the reverse lookup. I'd like to move to
> some better design that will allow the client side garbage collector (I
> am on about the one built into the JVM) to allow purges from the map.
> Clearly we need to move to an impl based on Weak References and also to
> an impl that is more efficient that to mutually pointing hashmaps.
>
> Once that purging map were in place the clientside factory could
> invisibly communicate back to the server which references were no longer
> used by a session. Thus in some stuttering nature, the distributed
> garbage collection works.
>
> Does anyone know where that hash map impl is? Did it get combined into
> commons-collections?
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [AltRMI] Two way weak hashmap for distributed garbage collection
Posted by Michael Smith <mi...@iammichael.org>.
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> I have searched for, but cannot find, a posting in this mail
> list some while ago that offered a "two way hashmap". We
> think we might be able to use it for distributed garbage
> collection.
[snip]
> Does anyone know where that hash map impl is? Did it get
> combined into commons-collections?
I think you're referring to DoubleOrderedMap:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/collections/src/java/o
rg/apache/commons/collections/DoubleOrderedMap.java?rev=1.1&content-type
=text/vnd.viewcvs-markup
It's not a hash based map though. It's red-black tree based.
regards,
Michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>