More ProxyComm issues: VLS-free operation?

[Mark S. Miller]

I believe the proxy comm system has been designed to allow operation without 
any running Vat Location Services (VLSs).  Indeed, with my current meager 
understanding of this code, I think I see mechanism attempting to achieve 
this, but it doesn't seem to succeed.  It seems the problems are confusions 
about search paths.

I'm not yet trying to create multiple vats in one jvm, as I await
resolution of the magic powers vs multiple instantiation issue (see previous 
note "proxy-comm issues.").  Currently I'm trying the simplest 
two-vat/two-jvm scenario.  I'm running both processes on my laptop while not 
connected to any network.  Since I normally do the SLIP/PPP thing, while I'm 
running disconnected I'm simply localhost/127.0.0.1, but this should still 
allow one local process to connect to another.


In EEnvironment.java, there is:

    /* Make sure there's a search path to us */
    String flattenedSearchPath = props.getProperty("e.SearchPath",
                //XXX Default is a hack for testing under Cafe
                "localhost:4567;localhost:4568");
    if (flattenedSearchPath == null || flattenedSearchPath.equals("")) {
       throw new RuntimeException("'e.SearchPath' property notspecified");
    }


and in ConnectionsManager.java, there is


 /*package*/ ConnectionsManager(KeyPair identityKeys, 
                                String /*nullOK*/ listenAddress,
                                Runner runner)
 {
     myIdentityKeys = identityKeys;
     myPLS = null;
     myLocalVatID = VatIdentity.calculateVatID(myIdentityKeys.getPublic());
        
     //XXX should use the e properties object (as held by the EEnvironment)
     myLocalFlattenedSearchPath = System.getProperty("SearchPath",
                 //XXX Default is a hack for testing under Cafe
                 "localhost:4567;localhost:4568");
     if (myLocalFlattenedSearchPath == null 
                || myLocalFlattenedSearchPath.equals("")) {
         Trace.comm.errorm(
            "You must specify the SearchPath property to create a "
            + "ConnectionsManager");
         Trace.comm.notifyFatal();
     }


1) I added one of the above "//XXX Default ... localhost:4568" cases above, 
by analogy with the other one, since the following tests are unhappy when 
there's no search path.


2) Tracing a warning if there's no search path would be fine, but tracing an 
error or throwing an exception seems excessive, as this is reasonable for 
completely vls-free operation, which we should allow.


3) Chip's comment above "//XXX should use the e properties object (as held 
by the EEnvironment)" is correct.  The ConnectionsManager constructors are 
called only by each other or by the overloads of 
VatIdentity.getConnectionsManager().  These are called only by each other or by

    public ProxyManager(VatIdentity vat,
                        String[] searchPath,
                        RegistrationTable registrations,
                        String listenAddress)
    {
        myVat = vat;
        mySearchPath = searchPath;
        myConnectionsManager = vat.getConnectionsManager(listenAddress);

How about if this last call is also passes searchPath as an argument, 
ultimately to be passed to the ConnectionsManager constructor?


     ******************  The Big One **********************

4) Most interestingly, the code that's apparently trying to enable vls-free 
operation is this in ConnectionManager:

    /*package*/ void listingAt(String listenAddress) {
        myListenAddress = listenAddress;
        if (null != listenAddress) {
            myLocalFlattenedSearchPath = listenAddress + ";" 
                    + myLocalFlattenedSearchPath;
        }
    }

which is called by the DataCommThunk, which is called by the ListenThread.  
It is correctly adding the TCP/IP address of this vat to this vat's search 
path, as known by the ConnectionsManager.  This would be fine if the search 
path were maintained in one place and shared.  Unfortunately, there's also a 
search path stored (at least) in the Registrar and the ProxyManager, and 
neither of these are updated.  Should these instead obtain the search path 
from the DataConnection?  Should there be an mutable search-path object 
that (at least) all three of these share, so they all see the update?

           *******************************************


5) Actually, even if these were shared, we still have a race condition.  The 
search path updating above happens later in the listen thread after 
everything is allegedly operational.  If something, such as the following, 
needs the search-path before the listen thread updates it, it could get a 
search-path that doesn't include our own listenAddress.


6) When you ask a Registrar to make a SturdyRef for an object, it uses the 
mySearchPath in Registrar, which is never updated to include our own 
listenAddress.


7) Could whoever wrote the following amazing comment


	/**
	 *  "I have seen things you would not believe..."
	 *
	 *  @see ListenThread.startup()
	 *  @see ListenThread.shutdown()
	 */
	/*package*/class UserThread extends Thread {

please clarify?  Thanks.


Any and all help would be greatly greatly appreciated!  Getting this all 
working again soon would be a very big deal.  In the meantime, I'm about to 
retreat to trying all this with VLSs.  I let y'all know how it goes.

	Cheers,
	--MarkM