Does RServeCLI2 support long running tasks?

Question

I am building an ASP.Net application that connects to Rserve on a Linux machine, using the library RserveCLI2.

I have done a test in which I increased the running duration of an R-script, to see if it will complete successfully. Below is my code.

  try
    {
        using (var rConnection = RserveCLI2.RConnection.Connect(_host, _port, _credentials))
        {
            rConnection.Assign("job.id", new SexpArrayInt(jobId));
            rConnection.Eval($"try(source(\"script.R\"), silent=T)");
            string errMessage = rConnection.Eval("geterrmessage()").ToString();
            if (errMessage == "")
            {   success = true; }
            else
            {   success = false; }
        }
    }
    catch (Exception e)
    {   success = false; }
    return success;

And the R script:

test.start <- Sys.time()
test.duration <- (1.2 ^ (job.id)) * 10 # in seconds.
test.i <- 0
while(as.numeric(difftime(Sys.time(), test.start), units="secs") < test.duration) {
     test.i <- test.i + 1 
}

The job.id is passed from Rserve an incremented by one on each iteration, effectively increasing the duration of each iteration by 20%. 5 iterations where running simultaneously, each started from a separate thread.

I found that the last job that completed lasted about 1 hour and 40 minutes. The following jobs did not complete within over 36 hours, when I stopped the test. No new jobs had been started.

If I interpreted it correctly, the Eval method never returned. On e Rserve server, I saw that only 2 Rserve processes remained of the 5 I had seen during the first hours of the test.

What could cause this behaviour and shouldn't RserceCLI2 return with an error?

Answer 1

This issues was caused by a network firewall and is not a problem of Rserve.

The client and server were communicating through a network firewall. This firewall is configured to block connections that have been idle for 2 hours. The connection is not actually closed. As I understand it, a firewall cannot do that, only the connected endpoints can.

So, probably, Rserve will send a response at some time, but this is never received by the client. The client will continue to wait for a response. I did not investigate how Rserve reacts to this.

We moved the client to another part of the network, where it could communicate with Rserve without the firewall in between.

I suppose sending OOB (out-of-band) commands could have solved the issue as well, functioning as a heart-beat, but I did not develop the R-package used, so that would have been quite complex to implement.