fs.createWriteStream stalls

Question

I am using the npm package busboy to parse a multipart form request and a write stream to write the sent file to disc.

This works fine with small files, but when I try with a larger file (7MB) it seems that only about 5MB is written to disc and then it seems that things stall and it never finishes and no error is thrown. This works locally but when running on ECS is where the problem occurs.

The node server is running in a docker container on ECS

  pipeline(fileStream, fs.createWriteStream(filePath), (err) => {
    if (err) {
      console.log("Pipeline failed", err);
    } else {
      console.log("Pipleline complete");
    }
  });

Any ideas??

Is there anything in front of your containers? API gateway? Load balancer? — Andrew Gillis, May 17 '21 at 02:28
Could you attach an error listener to the write stream itself? Not sure it makes a difference but it is weird it hangs with no message. — Andrew Gillis, May 17 '21 at 11:53
ALB was not playing nice when trying to upload large files. The request would take a while and then ALB would error - adding NGINX seemed to fix it. — pizzarob, May 17 '21 at 14:21
Sounds like it's just hidden the error. Maybe this is the culprit? https://serverfault.com/a/971297 — Andrew Gillis, May 17 '21 at 14:25
Yeah I have disabled http/2 already - I saw something like that. Unfortunately it doesn't seem to be the issue. — pizzarob, May 17 '21 at 15:09
@pizzarob the problem is you might need to debug this more effectively from the logs of ALB to Nginx and then check the chunk size that is being transferred. Unless we are sure that the entire file is being transferred from LB's till the function, it could become trial and error. — Nagaraj Tantri, May 19 '21 at 11:06
Have you thought of using an S3 bucket or Amazon EFS file system? Amazon already provides an SDK that simplifies the implementation of it. — diegochavez, May 20 '21 at 06:38
Do you have this same NGINX configuration on both environments? What is value of: `client_max_body_size`? — quentino, May 21 '21 at 12:13

score 2 · Answer 1 · answered May 21 '21 at 20:43

I recently solved this by finding the HTTP status codes that were "behind the scenes" by enabling access logging. In my case it was a 413 status code.

There's several steps to set this up, and it changes from time to time. Check the docs here for the current steps & config: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html#enable-access-logging

fs.createWriteStream stalls

1 Answers1