Using local UI with api.fnservice.io doesn't work

[nigeldeakin]

On 5th Feb 2018 the following issue was observed by @carimura

With UI running locally (in a local docker), connecting to the Fn server at api.fnservice.io, the UI server reported the following:

~/workspace/go/src/github.com/fnproject/ui master
❯ docker run --rm -it -p 4000:4000 -e "FN_API_URL=http://api.fnservice.io" fnproject/ui

> FunctionsUI@0.0.22 start /app
> node server

Using API url: api.fnservice.io
Server running on port 4000
GET http://api.fnservice.io/v1/apps, params:  {}
GET http://api.fnservice.io/stats, params:  {}
GET http://api.fnservice.io/stats, params:  {}
GET http://api.fnservice.io/stats, params:  {}
GET http://api.fnservice.io/stats, params:  {}
GET http://api.fnservice.io/stats, params:  {}
GET http://api.fnservice.io/stats, params:  {}
GET http://api.fnservice.io/stats, params:  {}
GET http://api.fnservice.io/stats, params:  {}
GET http://api.fnservice.io/stats, params:  {}
[ERR] ECONNRESET | An error ocurred.
Error. Api responded with  ECONNRESET An error ocurred.
GET http://api.fnservice.io/stats, params:  {}
[ERR] ECONNRESET | An error ocurred.
Error. Api responded with  ECONNRESET An error ocurred.
GET http://api.fnservice.io/stats, params:  {}
[ERR] ECONNRESET | An error ocurred.
Error. Api responded with  ECONNRESET An error ocurred.
GET http://api.fnservice.io/stats, params:  {}

I investigated this at the time: here is what I found.

If I have two command windows,

First window runs the fn ui locally: PORT=4000 FN_API_URL=http://api.fnservice.io npm start

Second window does while true; do curl http://api.fnservice.io/v1/apps;sleep 1; done to use a different endpoint of the API every second.

In a third window I start a browser on localhost:4000, which repeatedly polls the UI server, which in turn polls the Fn server on /stats.

I then see the UI server poll the Fn server successfully for a few seconds before failing in the same way as reported above. That means that it only took about half a dozen calls to /stats for this to happen.

Meanwhile, at the moment when the UI server starts reporting errors, my second window (with bash polling /v1/apps) also starts reporting errors as well

curl: (56) Recv failure: Connection reset by peer
curl: (52) Empty reply from server

If I close the browser, this stops the UI server in the first window polling /stats, and after a few seconds the second window recommences polling /v1/apps successfully.

Very curious. Now, in the first window, I kill the UI server, and instead run a bash command to poll /stats directly: while true; do curl http://api.fnservice.io/stats;sleep 1; done. This works just fine, indefinitely.

So there's something peculiar about the way that the UI server invokes /stats that is causing this particular Fn server to stop responding.

[nigeldeakin]

In an attempt to track down the cause of the issue, I made a guess at what the cause might be and made some changes (currently in PR https://github.com/fnproject/ui/pull/45) which allowed the number of sockets used by the UI to be configured.

I discovered that with maxSockets set to 1 (instead of the default), the problem went away. That doesn't fix the problem, but may help uncover the underlying issue (which may be in UI, in Fn, or in the particular way that fnservice.io is deployed.

[skinowski]

Seems like 'Connection: close' header causes this. Reproducible with:

curl -H 'Connection: close' http://api.fnservice.io/version

[skinowski]

Closing this as this seems like an env/deployment issue with api.fnservice.io.