[Mulgara-dev] ItqlInterpreter.isLocal problem

Andrae Muys andrae at netymon.com
Mon Oct 2 10:51:56 UTC 2006


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:
>>
>> On 01/10/2006, at 5:25 PM, Life is hard, and then you die wrote:
>>> This seems wrong: why would the local'ity of the previous server URI
>>> necessarily have anything to do with the locality of a new server  
>>> URI
>>> being set?
> [snip]
>>> The second case is in setServerURI(). Here I'm thinking the best
>>> option would be to either A) add a isRemote or isLocal parameter to
>>> the setServerURI() method, or B) to try to guess the value from the
>>> hostname using something like
>>>
>>>    String host = databaseURI.getHost();
>>>    boolean isLocal =
>>>        NetworkInterface.getByInetAddress(InetAddress.getByName
>>> (host)) != null;
>>>
>>> Does this make any sense? Am I missing something?
>>
>> 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> ;

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.

>> That it is causing you trouble is of concern, if Paul (or someone
>> else) hasn't been able to look at it by the time I have transactions
>> in hand, I'll see what I can do.
>
> Should I file a bug-report?

If you like, but see below; you probably want to file it against the  
documentation not mulgara.

>> Brian can probably comment here, but I thought that with the new
>> model URI/URN disambiguation code an rmi protocol in the URI always
>> attempted an RMI call.  So maybe the problem isn't the isLocal flag.
>> Have you tried "local:server#", 'local' is the nominated protocol for
>> accessing an embedded server.  Local here means 'in-process', so if
>> you are accessing via soap or rmi then !isLocal is correct.
>
> The reason we aren't using local:... is that there's another piece of
> software accessing the triplestore and that has rmi://localhost/
> hardcoded in it.
>
> 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.  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.

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

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

Andrae

-- 
Andrae Muys
andrae at netymon.com
Principal Mulgara Consultant
Netymon Pty Ltd





More information about the Mulgara-dev mailing list