danieljoos
commented
9 years ago The timeouts are intended to be on the level of a socket operation. So in case a socket operation, read/write/connect, does not complete within a given time, the socket itself can be considered to be in a bad state. Therefore it makes sense to close it, which leads to all outstanding handlers being called with an operation aborted.
We need to be careful on the read cases. At least for some (produce/fetch) requests the order is important.
The read-operation queue should preserve the order.
Maybe this type of requests should get handled different then other requests like metadata ones.
Nope, wouldn't do that.
Or do you plan to handle retries on a different level?
Yes, I wouldn't want to implement that kind-of stuff on the connection level.
any planes for the implementation of the whole client/producer/consumer logic?
Yes, working on it. :smile:
DEvil0000
If we hit a deadline for one of the operations we close the service no matter what deadline was hit. I think the different deadlines should get handled different.
connect_deadline-> retry connecting... (at least have the option)write_deadline-> retry sending... (at least have the option)read_deadline-> retry sending if the order is still fine... (at least have the option)We need to be careful on the read cases. At least for some (produce/fetch) requests the order is important. Maybe this type of requests should get handled different then other requests like metadata ones.
Or do you plan to handle retries on a different level?
BTW: any planes for the implementation of the whole client/producer/consumer logic?