I believe those relate to different problems. This is a scenario where part
of deserializarion is being outsourced to an external deserializer that is
not using the correct class loader. The suggested fix to the behavior of
the external serde seemed to have worked though I plan to follow up with
kryo on this issue.

On Thu, Aug 10, 2017 at 8:17 PM Thomas Weise <t...@apache.org> wrote:

> There are couple bugs that were recently identified that look related to
> this:
>
> https://issues.apache.org/jira/browse/APEXMALHAR-2526
> https://issues.apache.org/jira/browse/APEXCORE-767
>
> Perhaps the fix for first item is what you need?
>
> Thomas
>
>
> On Thu, Aug 10, 2017 at 8:41 PM, Pramod Immaneni <pra...@datatorrent.com>
> wrote:
>
>> I would dig deeper into why serde of the linked hashmap is failing. There
>> are additional logging you can enable in kryo to get more insight. You can
>> even try a standalone kryo test to see if it is a problem with the
>> linkedhashmap itself or because of some other object that was added to it.
>> You could try a newer version of kryo to check if the serde works in a
>> newer version because some big was fixed. Once you get more insight on the
>> cause then we would be in a better position to determine the best approach.
>>
>> Thanks
>>
>> On Thu, Aug 10, 2017 at 5:04 PM Vivek Bhide <vivek.bh...@target.com>
>> wrote:
>>
>>> Thanks Pramod.. This seems to have done trick.. I will check again when I
>>> have some data to process to see if that goes well with it. I am quite
>>> confident that it will
>>>
>>> Just curious, Is this the best way to handle this issue or if there is
>>> any
>>> other elegant way it can be addressed?
>>>
>>> Regards
>>> Vivek
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://apache-apex-users-list.78494.x6.nabble.com/How-the-application-recovery-works-when-its-started-with-originalAppId-tp1821p1829.html
>>> Sent from the Apache Apex Users list mailing list archive at Nabble.com.
>>>
>>
>

Reply via email to