[CRIU] checkpoint/restore full-fledged java applications

[Pavel Emelyanov]

On 11/23/2013 01:34 AM, Zuocheng Ren wrote:
> Hi all,
> I notice that in http://criu.org/What_software_is_supported, java is
> said to be partially supported. In one of my project, I need to use
> CRIU to checkpoint/restore full-fledged java applications which may
> have open sockets, open files, and etc. I'm wondering what's missing
> (if there is any at all) in the current CRIU/kernel implementation to
> make this possible?

Well, the reason for "partially" word in it is the lack of testing. So
far we have only checked very basic Java apps to get dumped and restored.

However, there have been a feedback from people doing some sort of genetic
Java tests generation. They said they used CRIU to speed things up and
reported only one issue with it (fixed immediately :) ).

That said, I think that you can try it. If there's any issue with dumping
or restoring, we'll be happy to help with resolving it.

> If there is anything that needs to be done, I'm
> happy to contribute on this aspect. Right now, I'm encountering some
> errors when restoring java applications. The error messages include
> "Can't open file /tmp/hsperfdata_<username>/<pid>", and "Thread pid
> mismatch". Any ideas of how to troubleshoot these issues? Thank you!

The "Can't open file" string can mean, that some file, that used to be on
disk during dump get lost at the time of restore. CRIU leaves it to the
caller to keep the filesystem state between dump-s and restore-s.

The 2nd message is trickier. When restoring a task or a thread we should
restore it with exactly the same pid/tid it used to have before dump.
However, if you are _not_ using pid namespaces, the desired pid can be
busy when you try to restore the task/thread. The message says exactly
this -- when the task/thread was created, the pid it wanted to obtain
was not available and the kernel allocated some other one.

Thanks,
Pavel