[Mulgara-dev] ItqlInterpreter.isLocal problem

[Life is hard, and then you die]

Thanks for the reply.

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.

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

> >FYI, the specific problem we're running into is that we're exporting
> >ItqlInterpreterBean via SOAP. Because isLocal defaults to false, and
> >because we're not running an RMI server (or registry) the calls all
> >fail (we're using "rmi://localhost/server" as the server URI).
> 
> 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.


  Cheers,

  Ronald