Re: Connection reset

2017-11-24 Thread Mohammad Noorani Bakerally
The same query:

PREFIX dcat: <http://www.w3.org/ns/dcat#>
PREFIX data: <http://opensensingcity.emse.fr/LDPDesign/data/>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX : <http://opensensingcity.emse.fr/LDPDesignVocabulary/>
CONSTRUCT { <https://bistrotdepays.opendatasoft.com/id/theme/
Sport%2C%20Loisirs> ?p ?o . } WHERE {  <https://bistrotdepays.
opendatasoft.com/id/theme/Sport%2C%20Loisirs> ?p ?o . }

if %2C%20
<https://bistrotdepays.opendatasoft.com/id/theme/Sport%2C%20Loisirs> is
removed from https://bistrotdepays.opendatasoft.com/id/theme/Sport%2C%
20Loisirs, it works even with the prefix unexpanded


So, the query below works !!:

PREFIX dcat: <http://www.w3.org/ns/dcat#>
PREFIX data: <http://opensensingcity.emse.fr/LDPDesign/data/>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX : <http://opensensingcity.emse.fr/LDPDesignVocabulary/>
CONSTRUCT { <https://bistrotdepays.opendatasoft.com/id/theme/SportLoisirs
<https://bistrotdepays.opendatasoft.com/id/theme/Sport%2C%20Loisirs>> ?p ?o
. } WHERE {  <https://bistrotdepays.opendatasoft.com/id/theme/SportLoisirs
<https://bistrotdepays.opendatasoft.com/id/theme/Sport%2C%20Loisirs>> ?p ?o
. }



‌

On Fri, Nov 24, 2017 at 2:02 PM, Mohammad Noorani Bakerally <
noorani.bakera...@gmail.com> wrote:

> A temporary solution for my problem, is that I expand the query and sends
> it, it's temporary because for logs or analysis of prefixes or whatever...
> it may not be the best thing to do
>
> Query gq = QueryFactory.create(Global.prefixes + queryStr);
> gq.setPrefixMapping(Global.prefixMap);
> gq.getPrologue().getPrefixMapping().clearNsPrefixMap();
> QueryExecution qe = QueryExecutionFactory.sparqlService(this.location, 
> gq.serialize());
>
>
>
>
> ‌
>
> On Fri, Nov 24, 2017 at 11:21 AM, Mohammad Noorani Bakerally <
> noorani.bakera...@gmail.com> wrote:
>
>> I think it's how the client is creating the request, since one client can
>> send it and get a reply and another cannot send or not properly creating it
>> such that low level programs cannot send the request, not sure though
>>
>> On 24 Nov 2017 10:58, "Andy Seaborne" <a...@apache.org> wrote:
>>
>>>
>>>
>>> On 24/11/17 09:30, Mohammad Noorani Bakerally wrote:
>>>
>>>> Just checked something, I've used the SPARQL Client YASGUI and the
>>>> sparql
>>>> query is answered properly, can we deduce that the issue is with the
>>>> client
>>>> ?
>>>>
>>>
>>> That would seem most likely, something on the network path from client
>>> to server - it is so hard to be definite about these low level errors.
>>>
>>> Andy
>>>
>>>
>>>>
>>>>
>>>> ‌
>>>>
>>>> On Fri, Nov 24, 2017 at 10:22 AM, Mohammad Noorani Bakerally <
>>>> noorani.bakera...@gmail.com> wrote:
>>>>
>>>> Yes, I'm going to check the logs, but so far, a query like SELECT *
>>>>> WHERE
>>>>> { ?s ?p ?o .} LIMIT 10 is properly handled and results is returned, I
>>>>> can
>>>>> share the sparql endpoint, it is http://opensensingcity.
>>>>> emse.fr/sparql/bistro, it's just for some testing purposes, so if I
>>>>> understand, if a query is answered, Fuseki must be properly configured
>>>>> with
>>>>> apache, the resets happens immediately and there is no delay, i've not
>>>>> checked the log but it seems the request doesn't even go to the server
>>>>>
>>>>>
>>>>> ‌
>>>>>
>>>>> On Fri, Nov 24, 2017 at 10:03 AM, Andy Seaborne <a...@apache.org>
>>>>> wrote:
>>>>>
>>>>> HttpException: -1 Unexpected error making the query:
>>>>>>> java.net.SocketException: Connection reset
>>>>>>>
>>>>>>
>>>>>> This is a problem at a low level in the networking stack (fake status
>>>>>> code -1 from Jena also says it's not an HTTP error).  The other end
>>>>>> responded with a TCP RST (the connection reset bit) which is attempt
>>>>>> to use
>>>>>> a connection the other end thinks is closed or does not exist.
>>>>>>
>>>>>> There are many reasons that can cause this - some kind of network
>>>>>> environmental issue between client and server.
>>>>>>
>>>>>> Having a reverse proxy (

Re: Connection reset

2017-11-24 Thread Mohammad Noorani Bakerally
A temporary solution for my problem, is that I expand the query and sends
it, it's temporary because for logs or analysis of prefixes or whatever...
it may not be the best thing to do

Query gq = QueryFactory.create(Global.prefixes + queryStr);
gq.setPrefixMapping(Global.prefixMap);
gq.getPrologue().getPrefixMapping().clearNsPrefixMap();
QueryExecution qe = QueryExecutionFactory.sparqlService(this.location,
gq.serialize());




‌

On Fri, Nov 24, 2017 at 11:21 AM, Mohammad Noorani Bakerally <
noorani.bakera...@gmail.com> wrote:

> I think it's how the client is creating the request, since one client can
> send it and get a reply and another cannot send or not properly creating it
> such that low level programs cannot send the request, not sure though
>
> On 24 Nov 2017 10:58, "Andy Seaborne" <a...@apache.org> wrote:
>
>>
>>
>> On 24/11/17 09:30, Mohammad Noorani Bakerally wrote:
>>
>>> Just checked something, I've used the SPARQL Client YASGUI and the sparql
>>> query is answered properly, can we deduce that the issue is with the
>>> client
>>> ?
>>>
>>
>> That would seem most likely, something on the network path from client to
>> server - it is so hard to be definite about these low level errors.
>>
>> Andy
>>
>>
>>>
>>>
>>> ‌
>>>
>>> On Fri, Nov 24, 2017 at 10:22 AM, Mohammad Noorani Bakerally <
>>> noorani.bakera...@gmail.com> wrote:
>>>
>>> Yes, I'm going to check the logs, but so far, a query like SELECT * WHERE
>>>> { ?s ?p ?o .} LIMIT 10 is properly handled and results is returned, I
>>>> can
>>>> share the sparql endpoint, it is http://opensensingcity.
>>>> emse.fr/sparql/bistro, it's just for some testing purposes, so if I
>>>> understand, if a query is answered, Fuseki must be properly configured
>>>> with
>>>> apache, the resets happens immediately and there is no delay, i've not
>>>> checked the log but it seems the request doesn't even go to the server
>>>>
>>>>
>>>> ‌
>>>>
>>>> On Fri, Nov 24, 2017 at 10:03 AM, Andy Seaborne <a...@apache.org>
>>>> wrote:
>>>>
>>>> HttpException: -1 Unexpected error making the query:
>>>>>> java.net.SocketException: Connection reset
>>>>>>
>>>>>
>>>>> This is a problem at a low level in the networking stack (fake status
>>>>> code -1 from Jena also says it's not an HTTP error).  The other end
>>>>> responded with a TCP RST (the connection reset bit) which is attempt
>>>>> to use
>>>>> a connection the other end thinks is closed or does not exist.
>>>>>
>>>>> There are many reasons that can cause this - some kind of network
>>>>> environmental issue between client and server.
>>>>>
>>>>> Having a reverse proxy (RP) in front of the Fuseki server is one
>>>>> possible
>>>>> cause e.g. when Fuseki isn't there but the reverse proxy is, there can
>>>>> be a
>>>>> rejection at the TCP level. Or the RP has rebooted reboot.
>>>>>
>>>>> There are many reasons (StackOverflow has many questions about this).
>>>>>
>>>>> Check the Fuseki server log - did the query even reach the server?
>>>>> Resets
>>>>> usually happen at the start (e.g after a long period of no use and the
>>>>> RP
>>>>> has timed the connection out (Fuseki, standalone, hasn't configured to
>>>>> Jetty to do this)..
>>>>>
>>>>> If it did reach the server, then some intermediate may have forcefully
>>>>> closed the connection.
>>>>>
>>>>>  Andy
>>>>>
>>>>>
>>>>> On 23/11/17 22:38, Mohammad Noorani Bakerally wrote:
>>>>>
>>>>> I am getting an exception when executing the following a valid
>>>>>> construct
>>>>>> query on Fuseki via jena. Any idea about this problem ?
>>>>>>
>>>>>> The query:
>>>>>> ==
>>>>>> PREFIX dcat: <http://www.w3.org/ns/dcat#>
>>>>>> PREFIX data: <http://opensensingcity.emse.fr/LDPDesign/data/>
>>>>>> PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
>>>>>> PREFIX : <http://opensensingcity.emse.fr/LDPDesignVocabulary/>

Re: Connection reset

2017-11-24 Thread Mohammad Noorani Bakerally
I think it's how the client is creating the request, since one client can
send it and get a reply and another cannot send or not properly creating it
such that low level programs cannot send the request, not sure though

On 24 Nov 2017 10:58, "Andy Seaborne" <a...@apache.org> wrote:

>
>
> On 24/11/17 09:30, Mohammad Noorani Bakerally wrote:
>
>> Just checked something, I've used the SPARQL Client YASGUI and the sparql
>> query is answered properly, can we deduce that the issue is with the
>> client
>> ?
>>
>
> That would seem most likely, something on the network path from client to
> server - it is so hard to be definite about these low level errors.
>
> Andy
>
>
>>
>>
>> ‌
>>
>> On Fri, Nov 24, 2017 at 10:22 AM, Mohammad Noorani Bakerally <
>> noorani.bakera...@gmail.com> wrote:
>>
>> Yes, I'm going to check the logs, but so far, a query like SELECT * WHERE
>>> { ?s ?p ?o .} LIMIT 10 is properly handled and results is returned, I can
>>> share the sparql endpoint, it is http://opensensingcity.
>>> emse.fr/sparql/bistro, it's just for some testing purposes, so if I
>>> understand, if a query is answered, Fuseki must be properly configured
>>> with
>>> apache, the resets happens immediately and there is no delay, i've not
>>> checked the log but it seems the request doesn't even go to the server
>>>
>>>
>>> ‌
>>>
>>> On Fri, Nov 24, 2017 at 10:03 AM, Andy Seaborne <a...@apache.org> wrote:
>>>
>>> HttpException: -1 Unexpected error making the query:
>>>>> java.net.SocketException: Connection reset
>>>>>
>>>>
>>>> This is a problem at a low level in the networking stack (fake status
>>>> code -1 from Jena also says it's not an HTTP error).  The other end
>>>> responded with a TCP RST (the connection reset bit) which is attempt to
>>>> use
>>>> a connection the other end thinks is closed or does not exist.
>>>>
>>>> There are many reasons that can cause this - some kind of network
>>>> environmental issue between client and server.
>>>>
>>>> Having a reverse proxy (RP) in front of the Fuseki server is one
>>>> possible
>>>> cause e.g. when Fuseki isn't there but the reverse proxy is, there can
>>>> be a
>>>> rejection at the TCP level. Or the RP has rebooted reboot.
>>>>
>>>> There are many reasons (StackOverflow has many questions about this).
>>>>
>>>> Check the Fuseki server log - did the query even reach the server?
>>>> Resets
>>>> usually happen at the start (e.g after a long period of no use and the
>>>> RP
>>>> has timed the connection out (Fuseki, standalone, hasn't configured to
>>>> Jetty to do this)..
>>>>
>>>> If it did reach the server, then some intermediate may have forcefully
>>>> closed the connection.
>>>>
>>>>  Andy
>>>>
>>>>
>>>> On 23/11/17 22:38, Mohammad Noorani Bakerally wrote:
>>>>
>>>> I am getting an exception when executing the following a valid construct
>>>>> query on Fuseki via jena. Any idea about this problem ?
>>>>>
>>>>> The query:
>>>>> ==
>>>>> PREFIX dcat: <http://www.w3.org/ns/dcat#>
>>>>> PREFIX data: <http://opensensingcity.emse.fr/LDPDesign/data/>
>>>>> PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
>>>>> PREFIX : <http://opensensingcity.emse.fr/LDPDesignVocabulary/>
>>>>> CONSTRUCT { <
>>>>> https://bistrotdepays.opendatasoft.com/id/theme/Sport%2C%20Loisirs> ?p
>>>>> ?o .
>>>>> } WHERE {  <
>>>>> https://bistrotdepays.opendatasoft.com/id/theme/Sport%2C%20Loisirs> ?p
>>>>> ?o .
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> The exception:
>>>>> 
>>>>> HttpException: -1 Unexpected error making the query:
>>>>> java.net.SocketException: Connection reset
>>>>>
>>>>> at org.apache.jena.sparql.engine.http.HttpQuery.rewrap(HttpQuer
>>>>> y.java:374)
>>>>> at org.apache.jena.sparql.engine.http.HttpQuery.execGet(HttpQue
>>>>> ry.java:337)
>>>>> at org.apache.jena.sparql.engine.http.HttpQuery.exec(HttpQuery.
>>>>> java:288)
>>>>> at
>>>>> org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConst
>>>>> ructWorker(QueryEngineHTTP.java:465)
>>>>> at
>>>>> org.apache.jena.sparql.engine.http.QueryEngineHTTP.execModel
>>>>> (QueryEngineHTTP.java:428)
>>>>> at
>>>>> org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConst
>>>>> ruct(QueryEngineHTTP.java:389)
>>>>> at
>>>>> org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConst
>>>>> ruct(QueryEngineHTTP.java:384)
>>>>> at
>>>>> loader.configuration.SPARQLDataSource.executeGraphQuery(SPAR
>>>>> QLDataSource.java:43)
>>>>> at genPLDPD.Evaluation.evalRM(Evaluation.java:136)
>>>>>
>>>>>
>>>>
>>>
>>


Re: Connection reset

2017-11-24 Thread Andy Seaborne



On 24/11/17 09:30, Mohammad Noorani Bakerally wrote:

Just checked something, I've used the SPARQL Client YASGUI and the sparql
query is answered properly, can we deduce that the issue is with the client
?


That would seem most likely, something on the network path from client 
to server - it is so hard to be definite about these low level errors.


Andy





‌

On Fri, Nov 24, 2017 at 10:22 AM, Mohammad Noorani Bakerally <
noorani.bakera...@gmail.com> wrote:


Yes, I'm going to check the logs, but so far, a query like SELECT * WHERE
{ ?s ?p ?o .} LIMIT 10 is properly handled and results is returned, I can
share the sparql endpoint, it is http://opensensingcity.
emse.fr/sparql/bistro, it's just for some testing purposes, so if I
understand, if a query is answered, Fuseki must be properly configured with
apache, the resets happens immediately and there is no delay, i've not
checked the log but it seems the request doesn't even go to the server


‌

On Fri, Nov 24, 2017 at 10:03 AM, Andy Seaborne <a...@apache.org> wrote:


HttpException: -1 Unexpected error making the query:
java.net.SocketException: Connection reset


This is a problem at a low level in the networking stack (fake status
code -1 from Jena also says it's not an HTTP error).  The other end
responded with a TCP RST (the connection reset bit) which is attempt to use
a connection the other end thinks is closed or does not exist.

There are many reasons that can cause this - some kind of network
environmental issue between client and server.

Having a reverse proxy (RP) in front of the Fuseki server is one possible
cause e.g. when Fuseki isn't there but the reverse proxy is, there can be a
rejection at the TCP level. Or the RP has rebooted reboot.

There are many reasons (StackOverflow has many questions about this).

Check the Fuseki server log - did the query even reach the server? Resets
usually happen at the start (e.g after a long period of no use and the RP
has timed the connection out (Fuseki, standalone, hasn't configured to
Jetty to do this)..

If it did reach the server, then some intermediate may have forcefully
closed the connection.

 Andy


On 23/11/17 22:38, Mohammad Noorani Bakerally wrote:


I am getting an exception when executing the following a valid construct
query on Fuseki via jena. Any idea about this problem ?

The query:
==
PREFIX dcat: <http://www.w3.org/ns/dcat#>
PREFIX data: <http://opensensingcity.emse.fr/LDPDesign/data/>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX : <http://opensensingcity.emse.fr/LDPDesignVocabulary/>
CONSTRUCT { <
https://bistrotdepays.opendatasoft.com/id/theme/Sport%2C%20Loisirs> ?p
?o .
} WHERE {  <
https://bistrotdepays.opendatasoft.com/id/theme/Sport%2C%20Loisirs> ?p
?o .
}



The exception:

HttpException: -1 Unexpected error making the query:
java.net.SocketException: Connection reset

at org.apache.jena.sparql.engine.http.HttpQuery.rewrap(HttpQuer
y.java:374)
at org.apache.jena.sparql.engine.http.HttpQuery.execGet(HttpQue
ry.java:337)
at org.apache.jena.sparql.engine.http.HttpQuery.exec(HttpQuery.java:288)
at
org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConst
ructWorker(QueryEngineHTTP.java:465)
at
org.apache.jena.sparql.engine.http.QueryEngineHTTP.execModel
(QueryEngineHTTP.java:428)
at
org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConst
ruct(QueryEngineHTTP.java:389)
at
org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConst
ruct(QueryEngineHTTP.java:384)
at
loader.configuration.SPARQLDataSource.executeGraphQuery(SPAR
QLDataSource.java:43)
at genPLDPD.Evaluation.evalRM(Evaluation.java:136)









Re: Connection reset

2017-11-24 Thread Mohammad Noorani Bakerally
Just checked something, I've used the SPARQL Client YASGUI and the sparql
query is answered properly, can we deduce that the issue is with the client
?



‌

On Fri, Nov 24, 2017 at 10:22 AM, Mohammad Noorani Bakerally <
noorani.bakera...@gmail.com> wrote:

> Yes, I'm going to check the logs, but so far, a query like SELECT * WHERE
> { ?s ?p ?o .} LIMIT 10 is properly handled and results is returned, I can
> share the sparql endpoint, it is http://opensensingcity.
> emse.fr/sparql/bistro, it's just for some testing purposes, so if I
> understand, if a query is answered, Fuseki must be properly configured with
> apache, the resets happens immediately and there is no delay, i've not
> checked the log but it seems the request doesn't even go to the server
>
>
> ‌
>
> On Fri, Nov 24, 2017 at 10:03 AM, Andy Seaborne <a...@apache.org> wrote:
>
>> > HttpException: -1 Unexpected error making the query:
>> > java.net.SocketException: Connection reset
>>
>> This is a problem at a low level in the networking stack (fake status
>> code -1 from Jena also says it's not an HTTP error).  The other end
>> responded with a TCP RST (the connection reset bit) which is attempt to use
>> a connection the other end thinks is closed or does not exist.
>>
>> There are many reasons that can cause this - some kind of network
>> environmental issue between client and server.
>>
>> Having a reverse proxy (RP) in front of the Fuseki server is one possible
>> cause e.g. when Fuseki isn't there but the reverse proxy is, there can be a
>> rejection at the TCP level. Or the RP has rebooted reboot.
>>
>> There are many reasons (StackOverflow has many questions about this).
>>
>> Check the Fuseki server log - did the query even reach the server? Resets
>> usually happen at the start (e.g after a long period of no use and the RP
>> has timed the connection out (Fuseki, standalone, hasn't configured to
>> Jetty to do this)..
>>
>> If it did reach the server, then some intermediate may have forcefully
>> closed the connection.
>>
>> Andy
>>
>>
>> On 23/11/17 22:38, Mohammad Noorani Bakerally wrote:
>>
>>> I am getting an exception when executing the following a valid construct
>>> query on Fuseki via jena. Any idea about this problem ?
>>>
>>> The query:
>>> ==
>>> PREFIX dcat: <http://www.w3.org/ns/dcat#>
>>> PREFIX data: <http://opensensingcity.emse.fr/LDPDesign/data/>
>>> PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
>>> PREFIX : <http://opensensingcity.emse.fr/LDPDesignVocabulary/>
>>> CONSTRUCT { <
>>> https://bistrotdepays.opendatasoft.com/id/theme/Sport%2C%20Loisirs> ?p
>>> ?o .
>>> } WHERE {  <
>>> https://bistrotdepays.opendatasoft.com/id/theme/Sport%2C%20Loisirs> ?p
>>> ?o .
>>> }
>>>
>>>
>>>
>>> The exception:
>>> 
>>> HttpException: -1 Unexpected error making the query:
>>> java.net.SocketException: Connection reset
>>>
>>> at org.apache.jena.sparql.engine.http.HttpQuery.rewrap(HttpQuer
>>> y.java:374)
>>> at org.apache.jena.sparql.engine.http.HttpQuery.execGet(HttpQue
>>> ry.java:337)
>>> at org.apache.jena.sparql.engine.http.HttpQuery.exec(HttpQuery.java:288)
>>> at
>>> org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConst
>>> ructWorker(QueryEngineHTTP.java:465)
>>> at
>>> org.apache.jena.sparql.engine.http.QueryEngineHTTP.execModel
>>> (QueryEngineHTTP.java:428)
>>> at
>>> org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConst
>>> ruct(QueryEngineHTTP.java:389)
>>> at
>>> org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConst
>>> ruct(QueryEngineHTTP.java:384)
>>> at
>>> loader.configuration.SPARQLDataSource.executeGraphQuery(SPAR
>>> QLDataSource.java:43)
>>> at genPLDPD.Evaluation.evalRM(Evaluation.java:136)
>>>
>>
>


Re: Connection reset

2017-11-24 Thread Mohammad Noorani Bakerally
Yes, I'm going to check the logs, but so far, a query like SELECT * WHERE {
?s ?p ?o .} LIMIT 10 is properly handled and results is returned, I can
share the sparql endpoint, it is
http://opensensingcity.emse.fr/sparql/bistro, it's just for some testing
purposes, so if I understand, if a query is answered, Fuseki must be
properly configured with apache, the resets happens immediately and there
is no delay, i've not checked the log but it seems the request doesn't even
go to the server


‌

On Fri, Nov 24, 2017 at 10:03 AM, Andy Seaborne <a...@apache.org> wrote:

> > HttpException: -1 Unexpected error making the query:
> > java.net.SocketException: Connection reset
>
> This is a problem at a low level in the networking stack (fake status code
> -1 from Jena also says it's not an HTTP error).  The other end responded
> with a TCP RST (the connection reset bit) which is attempt to use a
> connection the other end thinks is closed or does not exist.
>
> There are many reasons that can cause this - some kind of network
> environmental issue between client and server.
>
> Having a reverse proxy (RP) in front of the Fuseki server is one possible
> cause e.g. when Fuseki isn't there but the reverse proxy is, there can be a
> rejection at the TCP level. Or the RP has rebooted reboot.
>
> There are many reasons (StackOverflow has many questions about this).
>
> Check the Fuseki server log - did the query even reach the server? Resets
> usually happen at the start (e.g after a long period of no use and the RP
> has timed the connection out (Fuseki, standalone, hasn't configured to
> Jetty to do this)..
>
> If it did reach the server, then some intermediate may have forcefully
> closed the connection.
>
> Andy
>
>
> On 23/11/17 22:38, Mohammad Noorani Bakerally wrote:
>
>> I am getting an exception when executing the following a valid construct
>> query on Fuseki via jena. Any idea about this problem ?
>>
>> The query:
>> ==
>> PREFIX dcat: <http://www.w3.org/ns/dcat#>
>> PREFIX data: <http://opensensingcity.emse.fr/LDPDesign/data/>
>> PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
>> PREFIX : <http://opensensingcity.emse.fr/LDPDesignVocabulary/>
>> CONSTRUCT { <
>> https://bistrotdepays.opendatasoft.com/id/theme/Sport%2C%20Loisirs> ?p
>> ?o .
>> } WHERE {  <
>> https://bistrotdepays.opendatasoft.com/id/theme/Sport%2C%20Loisirs> ?p
>> ?o .
>> }
>>
>>
>>
>> The exception:
>> 
>> HttpException: -1 Unexpected error making the query:
>> java.net.SocketException: Connection reset
>>
>> at org.apache.jena.sparql.engine.http.HttpQuery.rewrap(HttpQuer
>> y.java:374)
>> at org.apache.jena.sparql.engine.http.HttpQuery.execGet(HttpQue
>> ry.java:337)
>> at org.apache.jena.sparql.engine.http.HttpQuery.exec(HttpQuery.java:288)
>> at
>> org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConst
>> ructWorker(QueryEngineHTTP.java:465)
>> at
>> org.apache.jena.sparql.engine.http.QueryEngineHTTP.execModel
>> (QueryEngineHTTP.java:428)
>> at
>> org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConst
>> ruct(QueryEngineHTTP.java:389)
>> at
>> org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConst
>> ruct(QueryEngineHTTP.java:384)
>> at
>> loader.configuration.SPARQLDataSource.executeGraphQuery(SPAR
>> QLDataSource.java:43)
>> at genPLDPD.Evaluation.evalRM(Evaluation.java:136)
>>
>


Re: Connection reset

2017-11-24 Thread Andy Seaborne

> HttpException: -1 Unexpected error making the query:
> java.net.SocketException: Connection reset

This is a problem at a low level in the networking stack (fake status 
code -1 from Jena also says it's not an HTTP error).  The other end 
responded with a TCP RST (the connection reset bit) which is attempt to 
use a connection the other end thinks is closed or does not exist.


There are many reasons that can cause this - some kind of network 
environmental issue between client and server.


Having a reverse proxy (RP) in front of the Fuseki server is one 
possible cause e.g. when Fuseki isn't there but the reverse proxy is, 
there can be a rejection at the TCP level. Or the RP has rebooted reboot.


There are many reasons (StackOverflow has many questions about this).

Check the Fuseki server log - did the query even reach the server? 
Resets usually happen at the start (e.g after a long period of no use 
and the RP has timed the connection out (Fuseki, standalone, hasn't 
configured to Jetty to do this)..


If it did reach the server, then some intermediate may have forcefully 
closed the connection.


Andy

On 23/11/17 22:38, Mohammad Noorani Bakerally wrote:

I am getting an exception when executing the following a valid construct
query on Fuseki via jena. Any idea about this problem ?

The query:
==
PREFIX dcat: <http://www.w3.org/ns/dcat#>
PREFIX data: <http://opensensingcity.emse.fr/LDPDesign/data/>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX : <http://opensensingcity.emse.fr/LDPDesignVocabulary/>
CONSTRUCT { <
https://bistrotdepays.opendatasoft.com/id/theme/Sport%2C%20Loisirs> ?p ?o .
} WHERE {  <
https://bistrotdepays.opendatasoft.com/id/theme/Sport%2C%20Loisirs> ?p ?o .
}



The exception:

HttpException: -1 Unexpected error making the query:
java.net.SocketException: Connection reset

at org.apache.jena.sparql.engine.http.HttpQuery.rewrap(HttpQuery.java:374)
at org.apache.jena.sparql.engine.http.HttpQuery.execGet(HttpQuery.java:337)
at org.apache.jena.sparql.engine.http.HttpQuery.exec(HttpQuery.java:288)
at
org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConstructWorker(QueryEngineHTTP.java:465)
at
org.apache.jena.sparql.engine.http.QueryEngineHTTP.execModel(QueryEngineHTTP.java:428)
at
org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConstruct(QueryEngineHTTP.java:389)
at
org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConstruct(QueryEngineHTTP.java:384)
at
loader.configuration.SPARQLDataSource.executeGraphQuery(SPARQLDataSource.java:43)
at genPLDPD.Evaluation.evalRM(Evaluation.java:136)


Connection reset

2017-11-23 Thread Mohammad Noorani Bakerally
I am getting an exception when executing the following a valid construct
query on Fuseki via jena. Any idea about this problem ?

The query:
==
PREFIX dcat: <http://www.w3.org/ns/dcat#>
PREFIX data: <http://opensensingcity.emse.fr/LDPDesign/data/>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX : <http://opensensingcity.emse.fr/LDPDesignVocabulary/>
CONSTRUCT { <
https://bistrotdepays.opendatasoft.com/id/theme/Sport%2C%20Loisirs> ?p ?o .
} WHERE {  <
https://bistrotdepays.opendatasoft.com/id/theme/Sport%2C%20Loisirs> ?p ?o .
}



The exception:

HttpException: -1 Unexpected error making the query:
java.net.SocketException: Connection reset

at org.apache.jena.sparql.engine.http.HttpQuery.rewrap(HttpQuery.java:374)
at org.apache.jena.sparql.engine.http.HttpQuery.execGet(HttpQuery.java:337)
at org.apache.jena.sparql.engine.http.HttpQuery.exec(HttpQuery.java:288)
at
org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConstructWorker(QueryEngineHTTP.java:465)
at
org.apache.jena.sparql.engine.http.QueryEngineHTTP.execModel(QueryEngineHTTP.java:428)
at
org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConstruct(QueryEngineHTTP.java:389)
at
org.apache.jena.sparql.engine.http.QueryEngineHTTP.execConstruct(QueryEngineHTTP.java:384)
at
loader.configuration.SPARQLDataSource.executeGraphQuery(SPARQLDataSource.java:43)
at genPLDPD.Evaluation.evalRM(Evaluation.java:136)
at genPLDPD.Evaluation.evalCM(Evaluation.java:53)
at genPLDPD.Evaluation.evalCM(Evaluation.java:67)
at genPLDPD.Evaluation.evalDD(Evaluation.java:33)
at Test7.virtualGraph(Test7.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at
org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:139)
at
org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:155)
at
org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:284)
at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at
org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
at
org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
at
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
at
org.apache.http.impl.client.cache.CachingExec.callBackend(CachingExec.java:592)
at
org.apache.http.impl.client.cache.CachingExec.handleCacheMiss(CachingExec.java:356)
at
org.apache.http.impl.client.cache.CachingExec.execute(CachingExec.java:275)
at
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at
org.apache.http.impl.execchain.Redire