[Mulgara-general] Can't connect to remote Mulgara repository using ConnectionFactory [SOLVED]
david.legg at searchevent.co.uk
Fri Nov 21 17:39:10 UTC 2008
>> Thanks also to Alex for suggesting the problem may be how the hostname
>> is setup on the server and to Ron for giving me the clue how to spot
>> it. When I tried pinging the server from the server I got 127.0.1.1
>> which is not only wrong... it is very wrong!
>> So... thanks all round.
> So, did that fix it for you?
For the benefit of future Ubuntu users listening here's what I did: -
I listed /etc/hosts and noticed two lines as follows:
I then changed the second line to read:
Where 192.168.1.10 is the fixed IP address I have assigned to my server
and optimus is the hostname of the server.
I then changed to /usr/local/mulgara which is where I keep the Mulgara
jar files and started up mulgara whilst logged in as root:
# $JAVA_HOME/bin/java -jar mulgara-2.0.6.jar
I could then successfully run my test RMI based program on another
remote machine and run a SPARQL query correctly and get the results back.
>> Paul, I think based on this experience I'm wholly in favour of being
>> able to eventually remotely access the full power of Mulgara through a
>> RESTful web interface. It is just so much more reliable, easier to
>> setup, easier to protect with a firewall etc.
> HTTP, yes. REST.... I'm not so sure about.
> REST requires that a URL always returns the same data. Unfortunately,
> if we have update operations on the database, then the returned data
> can change.
No that's not the case. If I created a restful URL called
'http://news.com/news/today' you wouldn't expect to get the same news
page forever more!
I think what your thinking of is "accessing a URL should have no side
effects". In other words if I access the same URL twice it shouldn't
have any undesired side effects; like paying for your shopping basket twice!
> The main thing missing from the HTTP setup is transactions.
Transactions can be handled in a Restful way too (once you've added
transaction support of course). The trick is to treat each transaction
as a first class object so just as you might PUT a new piece of data or
GET it back you can create a new transaction with a PUT or DELETE it
when you have finished. Effectively you are moving responsibility for
maintaining state between calls from the server to the client. If you
get time ;-) I'd urge you to get a copy of Richardson & Ruby's book
"RESTful Web Services" ISBN 0-596-52926-0 It makes a lot of sense
(after a few readings!).
More information about the Mulgara-general