You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the reasons why we run forked Lwt adapter for original httpaf is an ugly workaround for read backpressure - we add an Lwt_mutex per connection, which gets locked from above the http server when next buffer is pushed to Lwt_stream. If adding to stream blocks, mutex remains locked. Also this mutex gets locked from below http server - in Lwt adapter when trying to push data to state machine. This approach works, but slows things down. Since we're working on storage systems, we expect a lot of data to be ingested into our HTTP endpoints, and we need to throttle it in case we can't consume it that fast, instead of running out of memory :)
One of the reasons why we run forked Lwt adapter for original httpaf is an ugly workaround for read backpressure - we add an Lwt_mutex per connection, which gets locked from above the http server when next buffer is pushed to Lwt_stream. If adding to stream blocks, mutex remains locked. Also this mutex gets locked from below http server - in Lwt adapter when trying to push data to state machine. This approach works, but slows things down. Since we're working on storage systems, we expect a lot of data to be ingested into our HTTP endpoints, and we need to throttle it in case we can't consume it that fast, instead of running out of memory :)
Original httpaf issue for this matter has repro snippet: inhabitedtype/httpaf#140
The text was updated successfully, but these errors were encountered: