search

Dyalog / Jarvis

APL-based web service framework supporting JSON or REST
https://dyalog.github.io/Jarvis/
MIT License
33 stars 8 forks source link

Jarvis Threading Model #67

Closed PaulMansour closed 2 months ago

PaulMansour commented 2 months ago

Each HTTPHeader, HTTPBody, HTTPChunk and HTTPTrailer event is passed to HandleRequest in a new thread.

HandleRequest is wrapped in a :hold on the connection name.

I've recently discovered or rediscovered that :hold is not a fair mutex. So, if a few events on the same connection queue up on the :hold, I think they will not get access to the critical section in order.

This probably is not a big issue for un-chunked requests, as there are only two events that can happen (Header then Body), so there are never multiple threads waiting on the mutex (This could change if pipelining were implemented).

But I'm concerned about chunked messages. Is it not possible that chunks could queue up waiting for the mutex and then be serviced out of order?

bpbecker commented 2 months ago

Hi Paul!

I've conferred with Bjørn about how HTTP chunks are processed and he's confident that the they will be handled in the order sent.

PaulMansour commented 2 months ago

Is Bjørn confident that they are handled by Conga in the order sent (which I would hope) AND Jarvis (which is what I am concerned about)?

bpbecker commented 2 months ago

Ah, I have a better understanding now. It seems your observation is accurate. :hold doesn't implement a FIFO model. For non-chunked requests, there shouldn't be an issue (unless we decide to support pipelining) as the only one HTTPBody event will occur after the HTTPHeader event. But with a chunked request., chunks could get processed out of order. I've got some ideas on how to address this... watch this space...