[Mulgara-dev] ItqlInterpreter.isLocal problem

[Life is hard, and then you die]

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.
> 
> The RemoteResolver resolved distributed queries, a simple example:
> 
> select $s from <rmi://server1/db1#model> or <rmi://server2/db2#model>
> where $s <rdf:type> <my:class:of:interest> ;

My bad. I originally thought the ItqlInterpreter already handled
that. But looking at it again, I see that I was confused - the
updateSession() code supports this (i.e. supports the RemoteResolver),
but doesn't implement it. Sorry.

> 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.

Thanks. I think I understand it better now.

[snip]
> >The question is partly: is it a valid expectation that local sessions
> >can be created using rmi://localhost/... ? The examples in the docs
> >seem to think so. So if that's the case, then it seems to me there
> >should be a way to use rmi://localhost/... as a local session in the
> >ItqlInterpreterBean. If the rmi://localhost/... is more of an
> >accident, then I'll go patch that other piece of software.
> 
> My understanding is that if you are using an rmi:// URI then you will  
> use RMI regardless of if the instance is in-process or not.

Ok. That's not the way it's coded currently (it will try RMI, but fall
back to local: is isRemote is false).

> After  
> all it is perfectly legitimate to have a Mulgara instance running on  
> localhost listening for RMI connections AND an instance in-process  
> that does not have RMI activated and is accessed via local: URI's.   
> Ultimately the server URI in the query itself is a URL, as such the  
> protocol is *not* merely decorative.

Agreed.

> 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).

> Could you see if local: based URL's work; not really anything we can  
> do until we know if it is actually the problem.

Sorry, guess I forgot to say so before: yes, they do.

So I'll go the local:... route, and file a bug report against
ItqlInterpreter that either code or docs need updating.


  Cheers,

  Ronald