[srmi commit] r61 - wiki
codesite...@google.com
Date: Tue Dec 25 04:54:01 2007
New Revision: 61
Modified:
wiki/Notes.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/Notes.wiki
==============================================================================
--- wiki/Notes.wiki (original)
+++ wiki/Notes.wiki Tue Dec 25 04:54:01 2007
@@ -11,51 +11,39 @@
---
-identification mechanism for pass/return-by-remote : we use UUID ( and
on remote hosts, ip and UUID )
+Support remote constructor calls.
-I think constructors can't be called remotely ( cuz i can't override
them in the stub ! )
+Is inner class remoting an issue?
-Having inner classes accessing outer class fields creates methods that
is not public & not private access - not a problem anymore as we now
support non-public methods remoting, STILL untested
+Support remote fields.
-should i allow non-private remote fields ?
+Support polymorphism and generics. (Do annotations needs support ? I
mean if they want to check 'em in run-time).
-Note that all non-pass-by-remote parameters and return types are passed-by-value!
+IMPORTANT: Java users may assume a pass-by-reference and depend on its
behavior for some cases. In SRMI all non-pass-by-remote parameters and
return types are passed-by-value!
== SUGGESTIONS ==
-do we need RMIClassLoader to load remote objects ?
+Do we need to support remote class downloading, like RMIClassLoader
does using codebase value?
-system property env.class.path, we can use it to put tools.jar
automatically in the class path, we also may try to set srmi.basedir
to "." at run time if not set already
+IMPORTANT : Check that if there is a single instance of the server,
and multiple clients, that if we need synchronized or not. (Thread, RMI threads).
-IMPORTANT : check if we should make use of the synchronized
keyword !!! ( i.e. for the server functions so they are synchronized )
-
----> I do NOT support generics nor annotations yet.
+Optimize the clientside, don't create a client adapter for each
getRemoteObject, cache them. Or this will cause trouble (synchronization) ?
== HEAVY TASKS ==
IMPORTANT-BUG (solved) : handle locks for the race conditions for the
writing of the generated class files ( causes corrupted / truncated
class files ) ( even if using locks or synchronized keyword, it is only
affects a single JVM ... so what if multiple JVMs share the same
classes folder ? (this case is a must on one machine cuz rmiregistry
sees only one directory) ) --------- SOLUTION : using
java.nio.channel.FileLock, I obtain cross-JVM, machine-local-only locks.
-not-practical: all the generated class files must be in the working
directory of the rmi registry
-
== CRUCIAL ==
IMPORTANT-BUG: pass-by-remote of the same class ( class A () {
remote_A.private_method(); } ) for private functions, does not work (
calls local functions )
---| HOW do we tell other jvms that these have been unbound ? ( a
solution : they would discover by them selves, cuz there is the case of
a machine failure, refer to the java.rmi.dgc.leaseValue )
+How to handle hard and soft failure (departure) of a server object?
Keywords java.rmi.dgc.leaseValue.
-java.rmi.dgc.leaseValue REMOTE objects will disappear after that time
( default 10 minutes )
-|
-`-> this mechanism tells us in case a remote application crashed
automatically ( how to know that this happened ? )
+RMI disables objects after a certain inactive time
java.rmi.dgc.leaseValue which defaults to 10 minutes. How to get
notified that this happened (failure detection), and do we need a
keep-alive mechanism ??
== TODO FEATURES ==
+How to detect passable-by-remote with zero-code modifications ? is it
-logically- even possible ?
+PROPOSED SOLUTION : any class that is not Serializable and used as
param or return value and meets the SRMI conditions should be passed by
remote. OR any class that is used as param or return value even if
Serializable. This mean default is pass-by-remote, not pass-by-value.
Darkside: extreme overhead in case we don't really want it to be pass-by-remote.
-
-TODO : remove the check 'instanceof' pass-by-remote stub from the rmi
stub cuz it is done now inside the pass-by-remote stub constructor
-
-
-pass/return-by-remote for runtime types not only declared types.
-
-how to detect passable-by-remote with zero-code modifications ? is it
-logically- even possible ? PROPOSED SOLUTION : any class that is not
serializable and used as param or return val and meets the SRMI
conditions. OR any class that is used as param or return val even if
serializable ( sol to what we want pass by remote for serializable
classes ? ). This mean default is pass-by-remote, not pass-by-val (
extreme overhead in case we don't really want it to be pass-by-remote )
-
-in the server-side, there is only one instance of the server-side
wrapper for a certain object, does it make a difference if we tried to
achieve the same for client-side rmi-stubs ? ( currently each request
creates a new client-side rmi stub, what i want is some sort of caching
==> Does this introduce any synchronization issues ??? )
\ No newline at end of file
+Handle unserializable classes.
\ No newline at end of file