[CRIU] [Users] socket will take at least 0.5 seconds to recovery after docker restore done

[Yanbao Cui]

Correct my reply:

_existing_ migrated connections hang.

New connection (here I mean new socket or a new process, not as like
reconnection manually) is OK


Yanbao Cui <yygcui at gmail.com>于2015年7月14日 周二 22:07写道：

> _existing_ migrated connections hang.
>
> New connection is OK
>
> Pavel Emelyanov <xemul at parallels.com>于2015年7月14日 周二 21:59写道：
>
>> On 07/14/2015 04:43 PM, Yanbao Cui wrote:
>> > Server is working always and waiting. It seems the client, which is in
>> the container, cannot send data out after restored.
>> >
>> > For TCP, yeah, the client try to reconnect manually.
>>
>> You mean that after restore new connect()-s hang for a while? Why do
>> these connect()-s happen?
>> Or _existing_ migrated connections hang?
>>
>> > The delay is happened after restore successful, although the network is
>> recovered
>> >
>> >
>> > Pavel Emelyanov <xemul at parallels.com <mailto:xemul at parallels.com>>于2015年7月14日
>> 周二 21:31写道：
>> >
>> >     On 07/14/2015 04:15 PM, Yanbao Cui wrote:
>> >     > Sorry for mistake.
>> >     > For UDP, I mean the sever can receive the packet from client
>> again.
>> >
>> >     So where's the 0.5 seconds delay? Server sleeps and doesn't wake
>> up, packets
>> >     do not reach the server or something else?
>> >
>> >     > Actually, I have analysis the tcpdump output, in my case, the
>> client try to reconnect
>> >     > to the server again, but can not receive SYN+ACK, so it
>> re-transmission after 1 second
>> >     > according to the client rule, and then try again.
>> >
>> >     During migration we don't reconnect TCP (with regular SYN, SYNACK,
>> ACK sequence),
>> >     do you reconnect them manually?
>> >
>> >     -- Pavel
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150714/b4710999/attachment.html>