[Mulgara-dev] ItqlInterpreter.isLocal problem

[Paul Gearon]

Hi,

I spent my weekend on "paid work" activities, and didn't look in  
here.  Looks like a lot can happen in 2 days.

On Oct 2, 2006, at 7:01 PM, Life is hard, and then you die wrote:
> On Mon, Oct 02, 2006 at 08:51:56PM +1000, Andrae Muys wrote:
>> On 02/10/2006, at 6:27 PM, Life is hard, and then you die wrote:
>>> On Mon, Oct 02, 2006 at 01:03:25AM +1000, Andrae Muys wrote:
>>>>
>>>> I believe the isLocal flag is used to avoid loops when implementing
>>>> the RemoteResolver.  Paul is the best person to correct me in this,
>>>> but IIRC the serverURI is not always local when working with
>>>> distributed queries.  As the RemoteResolver was never released in
>>>> Kowari (it was a proprietary feature of TKS, the closed-source
>>>> version), this is not immediately apparent in Mulgara.  OTOH,
>>>> implementing a basic RemoteResolver is a relatively straight  
>>>> forward
>>>> proposition should anyone require it, and so it is probably best if
>>>> we don't remove the infrastructure required to support it.
>>>
>>> Thanks for the info. I understand that the serverURI is not always
>>> local. I don't quite understand the purpose of the RemoteResolver
>>> (or what exactly it is supposed to do, since ItqlInterpreter already
>>> seems to support remote server instances).
>>>
>>> I'll wait and see if Paul has a spare moment to enlighten me.

It's been a while since I looked at this, but I think that isLocal  
was for something other than loops on the remote resolver.

Almost every operation occurs over RMI.  This code path works well.   
However, there are some cases where the client is in the same JVM as  
the server.  I believe that *this* is what causes isLocal to return  
true.  Unfortunately, I also believe that this code path has  
problems, though they only show up in certain circumstances.  (No, I  
can't remember what these are.  It's been a while since I looked at  
this).

When is a client in the same JVM as the server?  The only case I know  
of is the example web interface which lots of people insist on using  
as their principle client.  Given that the server was never really  
designed to operate in a dual mode like this (both local and remote)  
I've never really liked this client.  It would all work perfectly if  
it were just in a separate JVM.  However, it has proven to be a very  
popular feature, so we're forced to keep it alive.

BTW, I've been tempted to re-do the remote resolver for Mulgara (in  
my copious spare time), since it was such a trivial implementation.   
However, it was a very naive implementation (as Andrae said) so there  
may not be a lot of call for it.  Still, it's useful if the machines  
have a good connection.

>> In this case rmi://server1 would be passed the entire query and the
>> URI rmi://server2 would be identified as !isLocal and server1 would
>> pass the appropriate query to server2 and combine the results.  The
>> RemoteResolver in TKS was naive, and consequently would be relatively
>> simple to reimplement.  Of course doing it efficiently requires quite
>> sophisticated query rewriting, and is decidedly non-trivial.

Actually, I always thought I could do it without query re-writing,  
but I'd be doing analysis on the query all the way through.  :-)

>> On the other hand this is a change from the behaviour of older
>> versions of Mulgara.  The change is a result of a bug fix contributed
>> by Brian Slatten (thanks Brian), it was referred to as "The Model  
>> URL/
>> URN conflation bug", and was the reason why Mulgara (then Kowari)
>> didn't like running on notebooks and other machines that changed
>> hostnames/IP-addresses.  The fix differentiates between the URN of
>> the model, a globally unique name for every Mulgara model, and the
>> URL used to refer to it in a query.  This URL<->URN mapping is a  
>> many-
>> to-one mapping, and is probably the cause of your difficulties.  It
>> is possible that some/all of the documentation hasn't been updated to
>> reflect the new arrangement, if so I apologise.  It is however an
>> important fix.  It will allow us to support multiple transport layers
>> (XML-RPC and REST are both near the top of the todo list).
>
> Interesting. And yes, I've found it slightly annoying that the model
> names essentially fixed the transport mechanism. So this is good stuff
> (though I saw Brian email about this not being in Mulgara yet).

I'm also looking forward to seeing this fix again.  Brian seems to be  
very busy at the moment, but I'm hoping he can do it soon.

Paul