flink-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maximilian Michels <...@apache.org>
Subject Re: How to avoid breaking states when upgrading Flink job?
Date Thu, 30 Jun 2016 11:38:32 GMT
Hi Josh,

You have to assign UIDs to all operators to change the topology. Plus,
you have to add dummy operators for all UIDs which you removed; this
is a limitation currently because Flink will attempt to find all UIDs
of the old job.


On Wed, Jun 29, 2016 at 9:00 PM, Josh <jofo90@gmail.com> wrote:
> Hi all,
> Is there any information out there on how to avoid breaking saved
> states/savepoints when making changes to a Flink job and redeploying it?
> I want to know how to avoid exceptions like this:
> java.lang.RuntimeException: Failed to deserialize state handle and setup
> initial operator state.
> 	at org.apache.flink.runtime.taskmanager.Task.run(Task.java:551)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException:
> com.me.flink.MyJob$$anon$1$$anon$7$$anon$4
> The best information I could find in the docs is here:
> https://ci.apache.org/projects/flink/flink-docs-master/apis/streaming/savepoints.html
> Having made the suggested changes to my job (i.e. giving a uid to every
> stateful sink and map function), what changes to the job/topology are then
> allowed/not allowed?
> If I'm 'naming' my states by providing uids, why does Flink need to look for
> a specific class, like com.me.flink.MyJob$$anon$1$$anon$7$$anon$4 ?
> Thanks for any advice,
> Josh

View raw message