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

[Saied Kazemi]

Are you doing external checkpoint restore, calling CRIU directly to dump
and restore the container, or are you using native "docker checkpoint" and
"docker restore" commands?  If latter, did you integrate C/R functionality
into Docker yourself?

--Saied


On Fri, Jul 17, 2015 at 5:56 AM, Yanbao Cui <yygcui at gmail.com> wrote:

> I use docker 1.6.0 and 1.6.2, they all have this problem.
>
> the needed files are shared via NFS.
>
> On Fri, Jul 17, 2015 at 11:15 AM, Saied Kazemi <saied at google.com> wrote:
>
>> Which Docker version are you using to checkpoint and restore your
>> containers?  Also, for migration, are you manually copying the container to
>> a target machine?
>>
>> --Saied
>>
>>
>> On Tue, Jul 14, 2015 at 7:36 AM, Yanbao Cui <yygcui at gmail.com> wrote:
>>
>>> 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
>>>>> >
>>>>>
>>>>>
>>> _______________________________________________
>>> CRIU mailing list
>>> CRIU at openvz.org
>>> https://lists.openvz.org/mailman/listinfo/criu
>>>
>>>
>>
>
>
> --
> Best Regards
> Cui Yanbao | 崔言宝
> --
> 龍生玖天，豈能安於凡塵！
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150717/594622da/attachment-0001.html>