Vivek,

Also a slightly more portable modification to what I suggested earlier is
to use kryo.getClassLoader() instead of
Thread.currentThread().getContextClassLoader()
in the JavaSerializer.

Thanks

On Thu, Aug 10, 2017 at 8:25 PM, Pramod Immaneni <pra...@datatorrent.com>
wrote:

> 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