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

Paul Gearon gearon at ieee.org
Fri Nov 21 00:46:13 UTC 2008

On Thu, Nov 20, 2008 at 6:06 PM, David Legg
<david.legg at searchevent.co.uk> wrote:
>> 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?
> Technically I'd say there is already a mechanism for this... it's called
> content negotiation [1] and is commonly handled via the
> content-disposition header [2] ;-)

I can do that. I'll leave the parameter option in though, since that
is easier to set up in many cases.

> Failing that... I think type or format is more descriptive than 'out'.

I agree... and I wrote it.  :-)  Every time I go to use this I want to
say "type" but I know that's wrong, so I have to look it up to remind
myself that it's "out". When the author can't even remember then
there's a problem. I have no idea what I was thinking at the time.

>> I thought that the data was all on the Linux server??? I'm confused here.
> I suspected that.  The intention is to keep the data on the Linux server
> and develop programs on the Windows machine that access the server.  I
> did also run Mulgara on the windows machine at one point  in an attempt
> to see if the connection problems only occurred in one direction and
> also to check if RMI worked when the server was located on the same
> machine as the client.

OK. I just hope that you're updating the hostnames in the query URLs I

> To sum up...
> 1. Running the test client program and Mulgara on the same machine works
> fine over RMI.
> 2. Running the client on one machine and Mulgara on another over RMI
> fails with a cannot connect failure.
>> 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.
> Thanks.  I think I'll have to go back to basics and check that I can
> make RMI work on this particular network.  The whole point of doing this
> is for future scalability so I want to get it right.

I have a trivial RMI program if you want to test the basic connectivity.

>> 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).
> You may have a point.  I'm rapidly going off RMI from a networking point
> of view!

I went off it a LONG time ago.  :-)

> The trouble is that while the vast majority of accesses to the
> server will be queries I will need to do updates too... although I
> suppose I could use the construct keyword for that?  I wonder if the
> overhead of having to re-parse the json or XML results before you can do
> something useful with them exceeds using RMI?

Well to do any kind of an update you need TQL anyway (since I haven't
had time to do SPARQL Update). I can't give you transactions yet
(sorry), but updates are perfectly fine over HTTP. That means you can
issue a DELETE and an INSERT quite easily.

As for overhead, I think that network speed far exceeds the overhead
of parsing JSON. XML is always slow, so I'm not going to place bets
there.  :-)

The SPARQL interface is on port 8080 by default (this is
configurable), and is at:

The TQL interface is on the same port, and is at:

Each interface accepts both GET and POST requests. Parameters have
slightly different meanings depending on GET or POST.

GET parameters
- query: This is either a SPARQL or a TQL query. When using GET to
access TQL, only SELECT queries are valid.
- out: either "xml" (the default) or "json"
- default-graph-uri: select the default graph for SPARQL. May be
specified more than once. Ignored by TQL.

A POST which includes a MIME content will be treated as a data upload.
You can use this to upload N3, Turtle, and RDF/XML files.

POST parameters:
- query: Any query or command, including commands that can change
- default-graph-uri: The destination graph for uploading data. Should
only be specified once.
        (If doing a SELECT in a POST, then this parameter acts the
same as for GET)

Yes, this needs documenting. Maybe I should copy/paste this email.  :-)


More information about the Mulgara-general mailing list