I removed that line from the code and it seems to have solved the problem.
Thank you very much! :)
All the best,
Laszlo
On Tue, Aug 17, 2021 at 9:54 AM László Ciople
wrote:
> Ok, thank you for the tips. I will modify it and get back to you :)
>
> On Tue, Aug 17, 2021 at 9:42 AM David Morávek wr
Ok, thank you for the tips. I will modify it and get back to you :)
On Tue, Aug 17, 2021 at 9:42 AM David Morávek wrote:
> Hi Laszlo,
>
> Please use reply-all for mailing list replies. This may help others
> finding their answer in the future ;)
>
>
>> sb.append(DeviceDetail.class.getName()).app
Hi Laszlo,
Please use reply-all for mailing list replies. This may help others finding
their answer in the future ;)
> sb.append(DeviceDetail.class.getName()).append('@').append(Integer.toHexString(System.identityHashCode(this))).append('[');
This part will again make your key non-deterministi
Great, let me know if that helped ;)
Best,
D.
On Mon, Aug 16, 2021 at 4:36 PM László Ciople
wrote:
> The events are json dictionaries and the key is a field which represents a
> device id, or if it doesn't exist, then actually a *hashCode *of the
> device object in the dictionary is used. So th
My intuition is that you have a non-deterministic shuffle key. If you
perform any "per-key" operation, you need to make sure that the same key
always end up in the same partition. To simplify this, it means that the
key needs to have a consistent *hashCode* and *equals* across different
JVMs.
Usua
