This object is in archive! 

Locus-Actions download timeout

zossebart shared this question 4 years ago
Answered

Hi,

I would like to find out if there is a builtin timeout for downloads initiated through a locus-actions URI.

It seems to me that there is a timeout around 25 seconds.

My server script sometimes needs a longer time to respond with data, but Locus teminates the download after about 25 seconds. The error I get form Locus is "rN, code: 10102".

Am I right with my assumption? If yes, would it be possible to increase this timeout?

Or could we even make it configurable through a parameter in locus-actions XML file?

Replies (3)

photo
1

Good day zossebart,

this is a weird problem. Error 10102 may really be a timeout, which is in the current public version set to 20 seconds. Anyway once the app starts streaming bigger files, this timeout has no effect. So is your server responding to Locus request within these 20 seconds? If you think, all should be ok, it is possible for me to test it on own device?

photo
1

hey menion,

thank you for your answer. No, I can not ensure that my script responds within 20 seconds. It does overpass-api queries (which have a configurable timeout) and after receiving the result, it analyzes/processes the returned data and finally outputs a gpx or zip-file.

With complex queries, the overpass-response can take quite some time...in the meantime, locus might have cancelled the download due to the timeout.

Do you say that my script only has to respond with SOMETHING first and afterwards the timeout is ignored, even if the rest of the data takes a long time to be generated?

Maybe I should return the http response header immediately, then do the overpass-query/processing and then the gpx-output later when it's ready? Would this be enough to prevent the timeout?

Or would I have to also return the beginning of the data (for example the gpx file header?).

photo
1

Hello,

not sure if this "Maybe I should return the http response header immediately, then do the overpass-query/processing and then the gpx-output later when it's ready?" is possible. You know better :).

Anyway, most simple solution ... I've added optional parameter "timeout" (in seconds) that may be added to XML definition.

So try please in next Beta version this:

	<download>
		<source size="123" date="2019-02-25_14-08-30" timeout="120">
			<![CDATA[..../file.zip]]>
		</source>
		<dest><![CDATA[/mapsVector/file.zip]]></dest>
		<after>extract|deleteSource</after>
	</download>
"timeout" parameter in "source" should work if I coded it correctly :). So let me know once you try it with next Beta version (will be published most probably tomorrow). Menion

photo
1

not sure if this "Maybe I should return the http response header immediately, then do the overpass-query/processing and then the gpx-output later when it's ready?" is possible. You know better :).

I think it should be possible, but I don't know if it would solve the problem ;-)


However, your proposed solution sounds perfect! Looking forward to next BETA to give it a try!

Thanks in advance!

photo
1

Hey Menion,


I did a quick test yesterday evening and it works like expected! Thank you very much!

photo
1

Perfect, glad it works!

photo
1

Thanks again for implementing this, works as expected in latest PRO. Didn't find this in the changelog, though ;-)

photo
1

Fine!

Well, I most probably considered this as so "tiny" thing, that it is hidden under "minor fixes" :)

Replies have been locked on this page!