0

I am testing a long running LocalGeoprocessingService using the ArcGIS Runtime Java SDK 10.2.4 (Linux 64 bit):

    LocalGeoprocessingService lgps = new LocalGeoprocessingService("/path/to/script.gpk");
    lgps.setServiceType(GPServiceType.SUBMIT_JOB);
    lgps.setMaximumRecords(Integer.MAX_VALUE);

    try {

        lgps.start();
        String serviceURL = lgps.getUrlGeoprocessingService();
        GPServiceInfo serviceInfo = null;

        try {
            serviceInfo = GPServiceInfo.fromUrl(lgps.getUrlGeoprocessingService());
        }

        catch (Exception e) {
            throw new RuntimeException(e);
        }

        String taskName = serviceInfo.getTasks()[0];
        Geoprocessor gp = new Geoprocessor(serviceURL + "/" + taskName);
        List<GPParameter> gpParameters = new LinkedList<>();
        gp.submitJobAsync(gpParameters,new CallbackListener<GPJobResource>() {

            @Override
            public void onCallback(GPJobResource gpJobResource) {

                ... do stuff 

            }

            @Override
            public void onError(Throwable throwable) {
                throw new RuntimeException(throwable);
            }
        });

At exactly 1 hour I always get the following stack trace, resulting from a timed out read:

  java.net.SocketTimeoutException: Read timed out

  at java.net.SocketInputStream.socketRead0(Native Method)
  at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
  at java.net.SocketInputStream.read(SocketInputStream.java:170)

  at java.net.SocketInputStream.read(SocketInputStream.java:141)



  at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:130)
  at org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:127)
  at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:233)
  at org.apache.http.impl.conn.DefaultResponseParser.parseHead(DefaultResponseParser.java:98)
  at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:210)
  at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:271)
  at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:227)
  at org.apache.http.impl.conn.AbstractClientConnAdapter.receiveResponseHeader(AbstractClientConnAdapter.java:209)
  at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:292)
  at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:126)
  at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:483)
  at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641)
  at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:731)
  at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:709)
  at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:700)



  at com.esri.core.internal.io.handler.h.a(Unknown Source)
  at com.esri.core.internal.io.handler.h.a(Unknown Source)
  at com.esri.client.local.LocalService.deleteService(Unknown Source)
  at com.esri.client.local.LocalService$d.run(Unknown Source)
  at com.esri.client.local.LocalService.stop(Unknown Source)

I see nothing in the API that would allow me to override the socket timeout, but I imagine there must be a way to do this, otherwise all jobs taking more than an hour to complete would be killed off -and someone would have surely run across this fairly major issue by now.

If the ESRI classes do not have a direct method to change this setting, is there any global setting on HttpClient that would override this behavior?

UPDATE

I also tried using a HttpRequestHandler:

    HttpRequestHandler.getInstance().setHttpRequestListener(new HttpRequestListener() {
        @Override
        public void onRequestInterception(HttpRequest httpRequest, HttpContext httpContext) {


            HttpParams params = httpRequest.getParams();
            HttpConnectionParams.setConnectionTimeout(params,100);
        }
    });

but this sadly just yields java.lang.UnsupportedOperationException: Setting parameters in a stack is not supported.

  • The timeout on the socket may be configured in the Server instance, since maximum runtime is a Server property. If the job does run that long, a little re-engineering is in order to manage the process asynchronously. – Vince Jan 31 '16 at 21:28
  • @Vince I don't see any option on 'com.esri.client.local.LocalServer' to set that property. Are you referring to another class? – THX1138 Jan 31 '16 at 21:36
  • Not a Java property, on the ArcGIS Server instance service itself. Again, any job running that long should be rewritten to be partitionable and asynchronous. – Vince Jan 31 '16 at 21:47
  • I am running the job asynchronously in the code above, but still get the SocketTimeoutException. I'm still a bit confused as to how/where I would set the property on the server - is it just an environment variable?. – THX1138 Jan 31 '16 at 22:06
  • No, the job itself is synchronous, which is why it can time out on the port. Asychronous execution would use a submit request and status polling. Server configuration is a completely different topic, and better asked as a new question (after some basic research on the parameter options). – Vince Jan 31 '16 at 22:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.