msg/async: support of non-block connect in async messenger #5681
Conversation
| { | ||
| int ret = ::connect(sd, (sockaddr*)&addr.addr, addr.addr_size()); | ||
|
|
||
| if (ret < 0 && errno != EISCONN) { |
There was a problem hiding this comment.
it maybe still in connecting(EINPROGRESS)?
There was a problem hiding this comment.
In reconnect , it must be wakened by poll(epoll) with an read event. That means it being connected or peer have sent some data to me. We can use reconnect to test whether it is connected or not. If it is connected, then errno will be EISCONN. If it is not connected, we will go to fail, and go to connecting again.
There was a problem hiding this comment.
Actually it may not only wake up from epoll. AsyncConnection has time event which also can wakeup and it maybe legacy so that wakeup connection when connecting
|
In my test, the second commit have serious problem. I close the fd in fault(). Let me correct it，and test |
…ry happen , it may mark osd down wrongly.
… we must set first_connect false
| if (r < 0) { | ||
| if (first_connect == true) { |
There was a problem hiding this comment.
What's the usage of "first_connect"?
There was a problem hiding this comment.
When first call nonblock_connect, if we call reconnect fail. We don't need to go to fail and retry, we just break. In other cases, we must retry.
When you have many breakdown peer, retrying may make msg thread busy, and also mark_down other peer wrongly.
There was a problem hiding this comment.
If r < 0, we should goto fail. Only when r == EINPROGRESS, we always need to break and retry later
There was a problem hiding this comment.
Do you mean "errno == EINPROGRESS"? Oh, at this time, the read event still exist. Yes, you are right.
There was a problem hiding this comment.
“2015-09-06 13:31:51.563489 7fcde1ffb700 20 -- :/1551015 >> 172.16.50.12:6789/0 conn(0x7fcde4171090 sd=18 :-1 s=STATE_CONNECTING_RE pgs=0 cs=0 l=1).process state is STATE_CONNECTING_RE, prev state is STATE_CONNECTING
2015-09-06 13:31:51.563497 7fcde1ffb700 10 NetHandler reconnect reconnect: Operation already in progress”
Subsquent calls to reconnect may return EALREADY, so we also check it. And let it to break?
|
@zuiwanyuan needs rebase your pull request against master to resolve the conflicts. and could you please
|
zuiwanyuan
changed the title
|
@zuiwanyuan , you could also |
|
@tchaikov , thanks you. I get it now. |
Async messenger should avoid all potential blocking point, but we use a block connect now.
So we must add this feature.