res.send is hanging, but when client is closing connection getting Eof error

[neimanpinchas]

Hi

I see great future for the weblink project, and trying to grasp it.

I am used to a pattern in express js that if I do not have the response immediately, or the response isn't a direct result from the request, than I am storing the res object in a global hashmap along with the ID, and when the responding routine would like to respond later in time, than the correct res is being looked up and used. I have another timeout routine that is periodically looping all responses and closing up the idle reses.

      public function respond_to(msg,id){

          try {
              var res=messages.get(id);
              trace("responding");
              if (res==null){
                  trace("respond not found, returning");
                  return;
              }
              res.send(msg);
              //res.socket.close(); 
              messages.remove(id);
          } catch(ex){
              trace("Failed to respond, the connection is maybe closed",ex);
          }
      }

I am trying to implement it in weblink and I sometimes am getting the following result, res.send is hanging, but when client is closing the connection it gets an Eof error, this was the most common error.

I've also had errors like hl: ./src/unix/stream.c:951: uv__write_callbacks: Assertion `uv__has_active_reqs(stream->loop)' failed. Aborted (core dumped)

I wonder if some pointers are being cleaned up after the route handler is being finished?

Not sure that the source of the issue is in weblink, it could be hashlink, libuv or GC related, ut as I am out of ideas on how to continue I would like to discuss it here as other weblink users might stumble into the same idiotic situation.

Thanks for any help

[neimanpinchas]

Not neecarily related to the issue but somewhat related to the header, so in case someone is trouble shooting a Hang

I just found another cause of hangs, if weblink runs on main thread than since haxe is pro "sync" it is very easy to have the main thread locked by a long File.getContent, or an upstream http request, and this will block all ongoing requests.

It is very importent to only use async operations on a high performance webserver (what weblink is for) or run weblink on a child thread, of course weblink will need proper mutexes and syncronozation every time it will need to access objects that are also accessible from other threads.

I do not have the project mentioned above to hand to rule out this cause, will update my findings