Hello!
To use the forum, login or register above.
(If you are already logged in above, please click here)
Suggestion: increase Keep-Alive timeout of api.brickowl.com
The HTTP 1.1 Keep-Alive timeout of api.brickowl.com is presently set at just one second, with a maximum query count of 100 per connection.
The BrickSync software never keeps more than 4 queries "in flight", only pipelining (queueing) more as previous ones are completed. This is meant to reduce the number of unknowns in cases where replies are never received (did the server actually receive and process the calls in flight or not?).
Unfortunately, that 1 second timeout means that the server can also close the connection between pipelined API calls whenever the internet tubes are clogged just a little (or using a shaky WiFi, etc.). The software then has no idea if the pipelined calls were processed or not, requiring to download the whole inventory back to figure things out.
Could the Keep-Alive timeout be increased to 3 seconds? Or even 5 seconds?... The Keep-Alive max of 100 could also be increased, but that's less bothersome.
Thank you!
The BrickSync software never keeps more than 4 queries "in flight", only pipelining (queueing) more as previous ones are completed. This is meant to reduce the number of unknowns in cases where replies are never received (did the server actually receive and process the calls in flight or not?).
Unfortunately, that 1 second timeout means that the server can also close the connection between pipelined API calls whenever the internet tubes are clogged just a little (or using a shaky WiFi, etc.). The software then has no idea if the pipelined calls were processed or not, requiring to download the whole inventory back to figure things out.
Could the Keep-Alive timeout be increased to 3 seconds? Or even 5 seconds?... The Keep-Alive max of 100 could also be increased, but that's less bothersome.
Thank you!
This discussion has been closed.
Powered by Vanilla
Comments
Some people use routers that make every closing socket looks like a network error. I guess such routers are "more efficient" because they cut short the FIN ACK socket goodbye handshake. Note that is very rude behavior in the high society of TCP packets.