Hi,
Thanks for the suggestion, I will definitely try this over the weekend.
I wonder if trying to restore it with parallelism = 1 could magically solve
this problem. Maybe that can give us some additional insights.
Cheers
Gyula
On Fri, Jun 23, 2017, 10:35 Stefan Richter
wrote:
> Hi,
>
> I had
Hi,
I had a closer look at those exceptions now, and I would expect so see this in
the case where there is suddenly a mismatch between the key-group range
assigned to the keyed backend and the key-groups covered by the state handle we
try to restore. For example like when the wrong state handle
Thanks Stefan for the tip, in this case I have a Long key so it's unlikely
that the hash code has changed. And as I mentioned I have several jobs with
the same exact topolgy which run just fine after migration.
It is super weird... Maybe I am blind to some stupid error, so I'll keep
looking.
Gyul
Hi,
I have seen the first exception in cases where the key had no proper and stable
hash code method, e.g. when the key was an array. What the first exception
basically means is that the backend received a key, which it does not expect
because determined by the hash the key belongs to a key gro
Hi all!
I am wondering if anyone has any practical idea why I might get this
error when migrating a job from 1.2.1 to 1.3.0? Idea on debugging
might help as well.
I have several almost exactly similar jobs (minor config differences)
and all of them succeed except for this single job. I have see
