GitHub user uce opened a pull request:
https://github.com/apache/flink/pull/2083
[FLINK-3713] [clients, runtime] Use user code class loader when disposing
savepoints
Disposing savepoints via the JobManager fails for state handles or
descriptors, which contain user classes (for example custom folding state or
RocksDB handles).
With this change, the user has to provide the job ID of a running job when
disposing a savepoint in order to use the user code class loader of that job or
provide the job JARs.
This version breaks the API as the CLI now requires either a JobID or a
JAR. I think this is reasonable, because the current approach only works for a
subset of the available state variants.
We can port this back for 1.0.4 and make the JobID or JAR arguments
optional. What do you think?
I've tested this with a job running on RocksDB state both while the job was
running and after it terminated. This was not working with the current 1.0.3
version.
Ideally, we will get rid of the whole disposal business when we make
savepoints properly self-contained. I'm going to open a JIRA issue with a
proposal to do so soon.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/uce/flink 3713-dispose_savepoint
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/flink/pull/2083.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2083
----
commit 1cdfe9b4df3584b3c3c48168cd3f17100dbebf4c
Author: Ufuk Celebi <[email protected]>
Date: 2016-06-08T08:59:24Z
[FLINK-3713] [clients, runtime] Use user code class loader when disposing
savepoint
Disposing savepoints via the JobManager fails for state handles or
descriptors,
which contain user classes (for example custom folding state or RocksDB
handles).
With this change, the user has to provide the job ID of a running job when
disposing
a savepoint in order to use the user code class loader of that job or
provide the
job JARs.
This version breaks the API as the CLI now requires either a JobID or a
JAR. I think
this is reasonable, because the current approach only works for a subset of
the
available state variants.
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
