socketTimeout Exception

Microwave Toolbox Problem Reports
#1

Hello

Since this afternoon, I am getting a SocketTimeout error when trying to run gpt to perform orbital correction. Is there an outage or something?

java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at sun.security.ssl.InputRecord.readFully(Unknown Source)
at sun.security.ssl.InputRecord.read(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readDataRecord(Unknown Source)
at sun.security.ssl.AppInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source)
at org.jsoup.helper.HttpConnection$Response.execute(HttpConnection.java:516)
at org.jsoup.helper.HttpConnection$Response.execute(HttpConnection.java:493)
at org.jsoup.helper.HttpConnection.execute(HttpConnection.java:205)
at org.jsoup.helper.HttpConnection.get(HttpConnection.java:194)
at org.esa.s1tbx.io.orbits.QCScraper.getFileURLs(QCScraper.java:73)
at org.esa.s1tbx.io.orbits.QCScraper.getFileURLs(QCScraper.java:64)
at org.esa.s1tbx.io.orbits.SentinelPODOrbitFile.getQCFiles(SentinelPODOrbitFile.java:271)
at org.esa.s1tbx.io.orbits.SentinelPODOrbitFile.downloadFromQCWebsite(SentinelPODOrbitFile.java:173)
at org.esa.s1tbx.io.orbits.SentinelPODOrbitFile.retrieveOrbitFile(SentinelPODOrbitFile.java:118)
at org.esa.s1tbx.sar.gpf.orbits.ApplyOrbitFileOp.updateOrbits(ApplyOrbitFileOp.java:256)
at org.esa.s1tbx.sar.gpf.orbits.ApplyOrbitFileOp.initialize(ApplyOrbitFileOp.java:190)
at org.esa.snap.core.gpf.internal.OperatorContext.initializeOperator(OperatorContext.java:485)
at org.esa.snap.core.gpf.internal.OperatorContext.getTargetProduct(OperatorContext.java:272)
at org.esa.snap.core.gpf.Operator.getTargetProduct(Operator.java:385)
at org.esa.snap.core.gpf.graph.NodeContext.initTargetProduct(NodeContext.java:77)
at org.esa.snap.core.gpf.graph.GraphContext.initNodeContext(GraphContext.java:195)
at org.esa.snap.core.gpf.graph.GraphContext.initNodeContext(GraphContext.java:178)
at org.esa.snap.core.gpf.graph.GraphContext.initNodeContext(GraphContext.java:178)
at org.esa.snap.core.gpf.graph.GraphContext.initNodeContext(GraphContext.java:178)
at org.esa.snap.core.gpf.graph.GraphContext.initNodeContext(GraphContext.java:178)
at org.esa.snap.core.gpf.graph.GraphContext.initNodeContext(GraphContext.java:178)
at org.esa.snap.core.gpf.graph.GraphContext.initNodeContext(GraphContext.java:178)
at org.esa.snap.core.gpf.graph.GraphContext.initOutput(GraphContext.java:162)
at org.esa.snap.core.gpf.graph.GraphContext.(GraphContext.java:91)
at org.esa.snap.core.gpf.graph.GraphContext.(GraphContext.java:64)
at org.esa.snap.core.gpf.graph.GraphProcessor.executeGraph(GraphProcessor.java:130)
at org.esa.snap.core.gpf.main.DefaultCommandLineContext.executeGraph(DefaultCommandLineContext.java:84)
at org.esa.snap.core.gpf.main.CommandLineTool.executeGraph(CommandLineTool.java:502)
at org.esa.snap.core.gpf.main.CommandLineTool.runGraph(CommandLineTool.java:350)
at org.esa.snap.core.gpf.main.CommandLineTool.runGraphOrOperator(CommandLineTool.java:249)
at org.esa.snap.core.gpf.main.CommandLineTool.run(CommandLineTool.java:150)
at org.esa.snap.core.gpf.main.CommandLineTool.run(CommandLineTool.java:122)
at org.esa.snap.core.gpf.main.GPT.run(GPT.java:54)
at org.esa.snap.core.gpf.main.GPT.main(GPT.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.esa.snap.runtime.Launcher.lambda$run$6(Launcher.java:55)
at org.esa.snap.runtime.Engine.runClientCode(Engine.java:189)
at org.esa.snap.runtime.Launcher.run(Launcher.java:51)
at org.esa.snap.runtime.Launcher.main(Launcher.java:31)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.exe4j.runtime.LauncherEngine.launch(LauncherEngine.java:62)
at com.exe4j.runtime.WinLauncher.main(WinLauncher.java:101)
at com.install4j.runtime.launcher.WinLauncher.main(WinLauncher.java:16)

Thanks,
Sanj.

1 Like
#2

PS> SNAP GUI orbit correction works just fine. I assume it may have something to do with protocol or IP address ?

#3

The data is retrieved from Sentinel-1 QC. If I try to download something manually from there it seems work.
Maybe @lveci knows what might go wrong.

#4

Okay - thanks Marco. Thats correct and it works fine with most of the files I am processing but for some it is throwing the error. e.g. the following S1A_IW_GRDH_1SDV_20151210T062205_20151210T062230_008976_00CDE1_1951.zip is one such case. SNAP didn’t report any corruption with the file.
thanks

#5

@lveci Any thoughts at all ? Is there to download all the orbit files offline and place it in the relevant auxdata folder so that app doesnt have to connect to the server?

thanks.

#6

Morning Marco, @iveci

I have done some further investigation and have established that the issue only takes place with following S1 files for 10th December 2015.

S1A_IW_GRDH_1SDV_20151210T173303_20151210T173324_008983_00CDF2_6601.zip
S1A_IW_GRDH_1SDV_20151210T062320_20151210T062345_008976_00CDE1_DD6A.zip
S1A_IW_GRDH_1SDV_20151210T062255_20151210T062320_008976_00CDE1_0256.zip
S1A_IW_GRDH_1SDV_20151210T062230_20151210T062255_008976_00CDE1_7BA8.zip
S1A_IW_GRDH_1SDV_20151210T062205_20151210T062230_008976_00CDE1_1951.zip

I also noticed that gpt appears to be connecting to a different server than the one you mentioned. According to the Network Packet Traffic Monitor, gpt is connecting to 131.176.235.71 (s1-mpcdmz-rep-v-52.sentinel1.eo.esa.int) on port 443.

The files look all okay and are not corrupt so how do I find out what might be causing this unexpected behaviour.

#7

Have this error too.

#8

I have been getting the same SocketTimeout error recently and have found a sort of workaround for batch scripting.

  • Go to the website mentioned by @marpet and filter for the orbit files that are valid for your images.
  • Download these .EOF files and compress to zip (for some reason, SNAP stores the zips as < orbitfilename >.EOF.zip instead of < orbitfilename >.zip so be careful with naming the zips).
  • Place these zip files in the SNAP user profile directory (for Windows it’s C:\Users\< user >\.snap\auxdata\Orbits\Sentinel-1\RESORB\< year >\ for Restituted Orbits)

In gpt, the Apply Orbit File operator should now properly locate the pre-downloaded orbit files and continue processing the graph.

#9

Thanks. I actually already have the files in the relevant auxdata folder so I am puzzled about the need to download the files again. Also, it is only happening for the files on the 10th December and only through gpt.

SNAP GUI processes the same files without any problem. I will download the files and follow your suggestion.

#10

That’s some interesting behaviour. By chance are you accidentally pulling the S1B orbit files, or the Precise when your graph requires Restituted? Only other thing I can think of is that the existing orbit files aren’t necessarily valid for those images (since the first date in the EOF is not the validity date)?

The error message appears to indicate that it can’t process the HTTP.GET request which should only be getting called if the orbit file can’t be found locally…

edit it looks like there isn’t any valid Restituted orbit information available for the 2015/12/10 06:xx:xx images link
The EOFs appear to go from validity times of V20151210T023009_20151210T054739 to V20151210T104352_20151210T140122

#11

In the next update S1TBX 4.0.3 the orbit files will be download individually instead of monthly so as to not take so long. Also, if the orbit is not found in our archive, SNAP will look at the QC website and download directly.

#12

Thanks. It should definitely help with processing time but for now, would I be correct in thinking that these restituted orbit files actually don’t exist in either archive or the QC website? Thanks.

#13

Update s1tbx to 4.0.4 and try again. Orbit downloading should be improved.

#14

And it has indeed! I can see that the app now looks for POE files when the ROE files are unavailable. Thanks! On a side note, I was wondering if it would help at all to compile the source code with JRockit JVM instead of the default (Hotspot) JVM?