that's the purpose of my pull request. the workerhook will now be statefull
compatible

Le lun. 9 avr. 2018 à 23:53, Mitchell Rathbun (BLOOMBERG/ 731 LEX) <
mrathb...@bloomberg.net> a écrit :

> Yeah you are right. So given that the WorkerHook is deserialized twice, I
> am wondering what the reason for this is. I feel like it isn't really
> stated anywhere in the documentation and assumed a WorkerHook would be
> deserialized once and reused. Given the current implementation, any members
> of a WorkerHook would have to be static right?
>
> From: user@storm.apache.org At: 04/09/18 16:05:06
> To: Mitchell Rathbun (BLOOMBERG/ 731 LEX ) <mrathb...@bloomberg.net>,
> user@storm.apache.org
> Subject: Re: Issues with WorkerHook when shutting down LocalCluster
>
> I think that the issue also exists in cluster mode. did you test it ?
>
> Le lun. 9 avr. 2018 à 21:50, Mitchell Rathbun (BLOOMBERG/ 731 LEX) <
> mrathb...@bloomberg.net> a écrit :
>
>> Just so I understand this correctly, the WorkerHook is created and then
>> serialized. It is then deserialized two separate times to call the start
>> and shutdown methods. This issue only happens in local mode, so what is the
>> difference between local mode and cluster mode in terms of how
>> serialization/deserialization of worker hooks is handled?
>>
>> From: user@storm.apache.org At: 03/29/18 01:55:45
>> To: user@storm.apache.org
>> Subject: Re: Issues with WorkerHook when shutting down LocalCluster
>>
>> Hi look at the pull request https://github.com/apache/storm/issues/2591
>> . The issue seems To be in all the current versions. You Will also find a
>> workaround  in the comments of the pullrequest.
>>
>> Le mer. 28 mars 2018 à 23:57, Mitchell Rathbun (BLOOMBERG/ 731 LEX) <
>> mrathb...@bloomberg.net> a écrit :
>>
>>> When shutting down our cluster in local mode using Storm version 1.1.1,
>>> we are running into the same problem as specified here:
>>> http://user.storm.apache.narkive.com/uchOrwlH/workerhook-deserialization-problem
>>>
>>> In the response, it was mentioned that a fix was implemented for a
>>> similar issue with cluster mode, but it doesn't seem that the local mode
>>> issue was fixed for version 1.1.1. Has this issue been fixed in newer
>>> releases, or is it an outstanding issue?
>>>
>>>
>>>
>>
>

Reply via email to