[Mulgara-general] Can't connect to remote Mulgara repository using ConnectionFactory

[Paul Gearon]

On Thu, Nov 20, 2008 at 4:14 PM, David Legg
<david.legg at searchevent.co.uk> wrote:
> Thanks Paul + Alex,
>
>>> So RMI can't connect to it at all, huh? What about HTTP? On the
>>> WIndows box, try to retrieve:
>>> http://SearchMaster:8080/sparql/?query=select+%24subject+%24predicate+%24object+from+%3Crmi%3A%2F%2FSearchMaster%2Fserver1%23sampledata%3E+where+%7B%24subject+%24predicate+%24object%7D
>>>
>
> That works!  I get an XML file downloaded containing the results.

OK. At least the server is up and running. BTW, you can get JSON
instead if you add a parameter of "out=json":

http://SearchMaster:8080/sparql/?query=select+%24subject+%24predicate+%24object+from+%3Crmi%3A%2F%2FSearchMaster%2Fserver1%23sampledata%3E+where+%7B%24subject+%24predicate+%24object%7D&out=json

Hmmm, now that I'm looking at it again, I'm wondering if "out" is the
best parameter name to use. Maybe it should be "type=json". Does
anyone have an opinion here?

>>> While typing this, it occurred to me to ask about your DNS. Is
>>> SearchMaster resolving to 192.168.1.10 for you?
>
> On optimus (the Linux server) SearchMaster (the Windows client) resolves
> to 192.168.1.1#53 using nslookup but if I type 'ping SearchMaster' it
> correctly uses 192.168.1.53

I thought that the data was all on the Linux server??? I'm confused here.

>>>  Try changing your
>>> graph name to:
>>> rmi://192.168.1.10/server1#sampledata
>>>
>>> You can also try the URL with addresses instead of host names:
>>> http://192.168.1.10:8080/sparql/?query=select+%24subject+%24predicate+%24object+from+%3Crmi%3A%2F%2F192.168.1.10%2Fserver1%23sampledata%3E+where+%7B%24subject+%24predicate+%24object%7D
>>>
>
> This doesn't bomb out but it does return error code 500 and Jetty
> announces that the query failed.

That may be because I thought the data was in a different place to
where it really is. Can you elucidate please?

>> This reminds me of another issue I've experienced in the past.  RMI connections
>> with a Mulgara server tend not to work unless the hostname on the server is
>> properly set (can be easily verified using the Linux 'hostname' command).  The
>> hostname needs to be a real hostname (not "localhost") which resolves to the
>> external interface (not the loopback address).  Otherwise RMI connections from
>> remote machines won't work; I'm not sure if this is a problem with the
>> canonicalization of server names that Mulgara does, or is deeper in Java RMI.
>>
>
> Running 'hostname' on the Linux server correctly returns 'optimus'.  I
> had an issue a while ago with optimus not seeing the windows machines on
> the network because of the lack of a DNS but the solution was to run
> winbind which makes use of netbios calls to find their names.  I suppose
> something in RMI might assume there is a DNS service?

If the data is on Optimus, then shouldn't we be referring to a graph
name of rmi://optimus/server1#sampledata ??? Now I'm starting to think
you're pointing the connection to the wrong server altogether, only
I'm not sure because you said that the query above worked.

My impression is that you've loaded the data onto Optimus, and you are
now trying to issue queries against Optimus from the Windows box
(which is named SearchMaster). If this is true, then you may not have
started the server in the correct location, since queries to the
Windows box for the data have been successful. If it is not true, then
perhaps you can explain again what you're doing?

> Ho hum, this is a real pain.  I was hoping to spend the last two days
> writing a Fresnel library to run natively over the connection to a
> remote Mulgara store.

It's supposed to be easy! I'm frustrated that you're having these
problems, and would like to help clear them up both for you and for
others who may run into it.

BTW, would the XML or JSON responses from URLs be suitable
replacements for what you're trying to do? The TQL interface isn't
transactional (I should look into that), but it's good for querying.
I'd suggest that it's preferable to using RMI for doing remote queries
(which is why I wrote it).

Paul