Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upClose/skip backpressure behavior switch #1056
Comments
|
Sending and publishing should never immediately call close handler as that often leads to complex recursion/reentry bugs. |
|
This makes a lot of sense to add. Some users would surely require an in-order stream where too much backpressure simply leads to a close rather than skip. Skipping is only valid for application protocols that do not deal with history where previous messages are important. Therefore this feature is important to add. |
|
maxBackpressure = number Shutting down the read side of the socket seems to work the same on BSD sockets and WinSock so using that feature sounds perfect here. |
|
I'm currently testing my backpressure handling by adding a DROP-rule to the firewall. I noticed i can send several MB's before i get a back-pressure build up. Is this normal? Where is the data stored? Is that size configurable? I would have expected to only be able to send maybe a few KB's before i got backpressure. Edwin |
|
Yes that's normal, the data is stored in kernel space. You can configure pretty much everything in this regard. |
It should be possible to enable the former close-on-backpressure behavior when pub/subbing
Probably add us_socket_deferred_close() as a way to close down the reading side thus causing error-close next iteration (?)