[Mulgara-general] Can't connect to remote Mulgara repository using ConnectionFactory
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":
>> 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  and is commonly handled via the
> content-disposition header  ;-)
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
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.
- 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.
- query: Any query or command, including commands that can change
data. These include: INSERT; DELETE; INSERT...SELECT; DELETE...SELECT;
CREATE; DROP; LOAD; EXPORT; BACKUP; RESTORE.
- 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