Hi James > -----Original Message----- > From: James Anderson <[email protected]> > Sent: Tuesday, July 6, 2021 1:00 PM > To: [email protected] > Subject: Re: Jena hangs while reading HTTP stream > > > > On 2021-07-06, at 12:46:47, John Walker <[email protected]> > wrote: > > > > Hi Andy > > > >> -----Original Message----- > >> From: Andy Seaborne <[email protected]> > >> Sent: Tuesday, July 6, 2021 12:04 PM > >> To: [email protected] > >> Subject: Re: Jena hangs while reading HTTP stream > >> > ... > >>>> John - what's the requestURL? The logs say the request is 3072 > >>>> bytes (including headers) which is possible but unusually large. > >>> > >>> As it is a GET request, the query text is passed as (url encoded) > >>> query string > >> parameter on the url. > >>> I cannot share the query text as it is for a customer project, but > >>> have made > >> similar GET request from curl and it came out at 3100 bytes. > >> > >> But what is it doing? I guess it is a CONSTRUCT query. > > > > Yes, it is a CONSTRUCT. > > > >> > >> At what point did it show as 3100 bytes? From "curl -v" or from logs > >> nearer. > >> the server? (Intermediates may be adding "Transfer-*" headers) > > > > To get that I just copied the request headers from curl -v output into a > > text > file and check the size. > > > > The original 3072 bytes comes from what James observed for the request > length on the Dydra host. > > the two length values are "$request_length/$body_bytes_sent" > > the first is described to be the length of the entire request. > (http://nginx.org/en/docs/http/ngx_http_log_module.html) > > the requests include the sparql query text as a url parameter. > one of the request lines was itself 2789 bytes. > > > > > >> > >> Andy > >> > >>>> > >>>> It is the unpredictability that is odd. > >>>> > >>>> Could you please breakpoint the process and see what code it is in? > >>> > >>> Will check on that. > > a stack trace could be very helpful.
There is no stack trace captured at the time of the incident and we are unable to reproduce. Given this sanitized extract from the application logs directly prior to it hanging: c.semaku.es.core.service.UpdateService : Executing : query.rq com.semaku.es.core.util.Utils : Send request to: https://example.com/foo/bar/sparql?query=query.rq com.semaku.es.core.util.Utils : Received response in 1397ms for https://example.com/foo/bar/sparql?query=query.rq c.semaku.es.core.service.UpdateService : Loading NTriples to Jena model The "received response in ..." line is logged after the HttpOp.execHttpGet() method has been called (which returns the TypedOutputStream). I am not familiar enough with how these streams work in Jena and Java. It is unclear if this indicates Dydra has started to return results after 1397ms, or if the complete response had already been received by the client. > > >>> > >>>> > >>>> Andy > >>> > >>> John
