[Mulgara-dev] Emailing: protocolServlet POST answercleanup.patch

[David Smith]

Thanks for answering.

Yes, we're switching from SOAP to REST.
Yes, the system has been working correctly under SOAP.

We were seeing performance/scaling issues, with slow progress through
our actual work, 
with very small actual demand on the server. Something is/was blocking
somewhere.

After working through some .NET configuration issues with calling REST
services, we started working with the JETTY configuration settings.
These did not seem to help us with the calling through the SOAP
interface. 

Then we tested with the REST interface and did see better performance.
Moved everything and in testing we're seeing the logs flooded (really a
lot) with these messages. Mulgara seems to bog down (significantly --
this time very busy but still not responding well) and not knowing what
else to chase suspected the Answer close issue (and/or the actually log
generation). Maybe something to test is commenting out the log() entry
in the TransactedAnswer finalize.

We switched to REST/POST because current the system used one internal
interface to get to mulgara (no matter the actual query). I may go
through and separate out the pure SELECTs and switch to GET... but have
not so far.

The only real problem so far was one case where the SOAP call included
multiple SELECTs and took advantage of the single response <ANSWER> with
multiple <QUERY><SOLUTION>... sections.

Ok, so it's worth keeping the session logic.
The earlier patch was to let us use the REST/POST with queries with
subqueries.
The patch below was my attempt to make sure the answers were being
closed.
Can you point me at an example of correctly closing Answers with
subqueries involved. I tried looking and didn't see them.


Dave S



-----Original Message-----
From: mulgara-dev-bounces at mulgara.org
[mailto:mulgara-dev-bounces at mulgara.org] On Behalf Of Paul Gearon
Sent: Tuesday, January 19, 2010 2:52 PM
To: Mulgara Developers
Subject: Re: [Mulgara-dev] Emailing: protocolServlet POST
answercleanup.patch

On Tue, Jan 19, 2010 at 2:29 PM, David Smith <DMS at viewpointusa.com>
wrote:
> Yes, how would that effect the .close()?

Subqueries result in subanswers, each of which need to be closed.
Interfaces that iterate over data for you are supposed to close these
as they go, but if they're not then you'll get these messages if the
log. Subqueries of this type don't exist in SPARQL (and SPARQL 1.1
subqueries have a different kind of structure), so new systems haven't
been testing this very much. Besides that, these messages are not
fatal, so even if we were testing those queries, they'd still be
passing.

So to check.... you said you're converting from SOAP to REST? Do you
mean that you were using the SOAP interfaces successfully, and now
you're moving over to using the REST interfaces instead?

> A side question (actually prompted by your query cancelation
discussion)...
>
> Should REST clients still preserve the Jetty session? (we do), but I
really have switched to using the POST auto commit handling around a
POST query with multiple statements -- rather than doing our own
autocommitt off/on.

The system does use the Session to cache the current connection. If
you don't preserve it, then it will ask for a new Connection each
time. Since the ConnectionFactory caches connections by server, then
if you don't store the http session then you'll possibly get the same
connection anyway.

> I see that mulgara connections are cached by the session, but it also
seems that connections to the same server are "pooled".
> Is this correct?

Pretty much.

> >From a performance stand point would it be better to use sessions.

Do you mean HTTP sessions or Mulgara Session objects? All the same, if
you use HTTP sessions then it will come to the same thing (since the
session will refer to a Mulgara Connection, which wraps a Mulgara
Session). And yes, I'd use the same session wherever possible, since
it will prevent the possibility of reestablishing a new Connection.

Regards,
Paul
_______________________________________________
Mulgara-dev mailing list
Mulgara-dev at mulgara.org
http://mulgara.org/mailman/listinfo/mulgara-dev

This E-Mail may contain confidential and privileged information. It is intended solely for the recipient(s) indicated. Any review, use, or distribution by anyone other than the intended recipient(s) is strictly prohibited. If you have received this E-Mail in error or are not the intended recipient, please notify the sender and delete all copies immediately.