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) < [email protected]> 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: [email protected] At: 04/09/18 16:05:06 > To: Mitchell Rathbun (BLOOMBERG/ 731 LEX ) <[email protected]>, > [email protected] > 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) < > [email protected]> 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: [email protected] At: 03/29/18 01:55:45 >> To: [email protected] >> 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) < >> [email protected]> 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? >>> >>> >>> >> >
