Frequent HTTP timeouts when communicating with 4store

[Rob Vesse]

I've been experimenting with using 4store as the backend storage for
my work but I've found that when communicating with it via the HTTP
protocol I seem to get an unreasonably high percentage of errors due
to HTTP timeouts.

My code basically does a series of read and write operations to 4store
using SPARQL CONSTRUCT for the reads and using HTTP PUT for the
writes. Is there some limitation on how many queries and updates
4store can serve at once?

The code was multi-threaded but even when reduced to a single thread I
still experience the same issue.

Any ideas on what might be the cause of the issue or how I could work
around it?

Rob Vesse

[Steve Harris]

You can only have one write occurring at once, but you can have reads
going on while there is a write happening.

Are the timeouts occurring with reads or writes? Also, the timeoout
time is set in your client, so you could try turning it up. The
default may be low.

- Steve

> --
>
> You received this message because you are subscribed to the Google
> Groups "4store-support" group.
> To post to this group, send email to 4store-...@googlegroups.com.
> To unsubscribe from this group, send email to 4store-suppor...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/4store-support?hl=en
> .
>
>

[Rob Vesse]

The timeouts occur on both reads and writes - running the code
repeatedly will result in timeouts at different points. I've got the
timeout for reads set to 60 seconds and the timeout for writes is set
to 100 seconds.

I've also tried adding the use of a Reader/Writer lock on the
connection so only one write can be attempted at once and reads can't
happen while a write is in progress but this has made no difference.

What is 4store's behaviour in the case that a read request is made
while a write is happening, does it wait for the write to complete or
does it just not perform the read? Is there any way of determining
how long a write will take to process so an appropriate delay could be
inserted in making requests?

Rob

[Steve Harris]

I believe that reads should happen immediately, though if there's high
IO load the performance might go down, and there might be a delay.

Writes will be queued if you try to send more than one at once, so it
should be fine, as long as your connection doesn't time out while it's
queued, so there should be no need to delay.

- Steve

[Rob Vesse]

So I still have this error so I'm not sure if this is maybe some
logical error in how the C# connector I've written as part of
dotNetRDF works or if this is some fundamental limitation within
4store.

To recap the reads are done via SPARQL CONSTRUCT queries and the
writes via HTTP PUT and I get frequent HTTP time-outs

I've put together a little demo application which demonstrates this,
it takes a very small graph (58 triples) and attempts to repeatedly
write the graph to 4store and then read it back again. I wonder
whether the fact that I'm overwriting an existing Graph in the store
is part of the problem since the 1st write and read are almost
instantaneous but after the 2nd write it hangs? But I've tried it
when I use a different Graph URI for each write/read attempt and I get
exactly the same behaviour.

The demo application can be checked out of SVN here:
https://dotnetrdf.svn.sourceforge.net/svnroot/dotnetrdf/samples/4s-stress-test

Run the 4s-stress-test.exe file from the bin\Debug directory

It's a Windows command line application that prompts for a URI for a
4store server and the option of using a different Graph URI for each
iteration before attempting to do 100 write/read attempts in
sequence. I was hoping to have this run under Mono but I've found
what may be a bug in the Mono runtime which prevents this currently.

Can you guys take a look and tell me what you think?

Rob

[Rob Vesse]

So I figured out the source of the problem thanks to a thought a
colleague had in the pub last night!

The problem was that I wasn't explicitly closing the connection to
4store after a POST operation whereas with the read operations the
connection always gets closed. This causes an issue since .Net's HTTP
model will permit only two concurrent connections to a given domain at
a time so once two writes were done I had two open connections to my
4store instance which blocked any more connections from being made
hence the timeouts.

So this was primarily a bug in my code but I'm wondering whether
4store is not closing connections at it's end, I have connectors for
other stores that use a similar pattern which never had this problem
(though I've now applied the fix universally for good measure) so I
don't know if 4store isn't closing requests properly after responding.

[Nick Lamb]

Thanks Rob for letting us know you found the problem.

I had looking into this down for today and I wasn't enthusiastic about
trying to reproduce the problem via running a Windows executable, so
you saved me some time there.

I believe that 4store does close connections once it has finished with
them. An earlier generation of the code had a double-close bug and we
put some effort into making sure it closed each socket exactly once.
Is it possible that the difference with other stores is that they
speak HTTP/1.1 and so you can re-use the connections whereas 4store
only does HTTP/1.0 with exactly one connection per operation ?

I would be interested in adding HTTP/1.1 support to 4store, but I am
quite busy for the forseeable future. In theory offering HTTP/1.1
could reduce the setup/ teardown overhead and would show a performance
improvement for some use cases, particularly with longer network
latencies. So, for long imports or slow queries on the local machine
it would make no difference, but if doing many sequential fast queries
over the Internet (where latencies often exceed 100ms) it could be a
very large improvement.

It's possible that quality of implementation issues that forbid the
full exploitation of HTTP/1.1 by web browsers (basically, too many web
servers crash, corrupt data or have other unacceptable behaviour
unless you limit yourself to a "known safe" subset of the
specification) need not apply to SPARQL, and we could thus get some
performance wins from offering HTTP/1.1 features like pipelining.