stdpain opened a new issue, #2477:
URL: https://github.com/apache/brpc/issues/2477
**Describe the bug (描述bug)**
In our application there are a series of RPC calls. the response time on the
opposite end is variable. For example, if I initiate 4 RPCs in a row, it will
take a few seconds or more for the other end to respond. Then more short RPC
requests may be initiated. Repeating this process will cause the ABAList length
to increase until the EAGAIN error. However, I'm not better at the application
layer to tell in advance that a request is a long request.
```c++
template <typename Id, typename IdTraits>
int ListOfABAFreeId<Id, IdTraits>::add(Id id) {
// Scan for at most 4 positions, if any of them is empty, use the
position.
Id* saved_pos[4];
for (size_t i = 0; i < arraysize(saved_pos); ++i) {
Id* const pos = _cur_block->ids + _cur_index;
forward_index();
// The position is not used.
if (*pos == IdTraits::ID_INIT || !IdTraits::exists(*pos)) {
*pos = id;
return 0;
}
saved_pos[i] = pos;
}
....
if (_nblock * IdTraits::BLOCK_SIZE > IdTraits::MAX_ENTRIES) {
return EAGAIN;
}
```
I know that Pooled mode may alleviate this problem, but it doesn't
completely avoid it code-wise. At the same time I don't really want to use
short connection mode.
So I'm thinking about optimising the ABAList logic.
1. when ABAList length exceeds a certain size, try more probes
2. when ABAList reaches the upper limit, try to traverse the list to find
the next available position.
**Versions (各种版本)**
OS:
Compiler:
brpc: 1.3.0+
protobuf:
**Additional context/screenshots (更多上下文/截图)**
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org
For additional commands, e-mail: dev-h...@brpc.apache.org
