Vyacheslav, Thanks for investigating this. User code should never listen to system custom events because this is an internal API and it's a subject to change. If there is anything a user interested in, the corresponding public event should be added.
Nullifying the event in this case looks ok for me. вс, 30 сент. 2018 г. в 11:45, Vyacheslav Daradur <daradu...@gmail.com>: > I think that I understand a reason for doing this: > The most custom events which handle in > 'GridDhtPartitionsExchangeFuture' are using only in PME flow and > reason is release them for GC as soon as possible. > > But there are some other systems which can listen to the same events, > for example, to perform activation/deactivation actions them should > handle [ChangeGlobalStateMessage, ChangeGlobalStateFinishMessage] > which can be reset to 'null' by PME earlier then they will be handled > by other systems. > > I'd suggest do not reset to 'null' custom messages in > 'DiscoveryCustomEvent ' (at least without properly logic from the > discovery-spi side). > > Thoughts? > > > > On Sat, Sep 29, 2018 at 11:43 PM Vyacheslav Daradur <daradu...@gmail.com> > wrote: > > > > Hi Igniters! > > > > I think I found an illegal behavior in > > GridDhtPartitionsExchangeFuture#onDone, the following code is called > > here: > > ((DiscoveryCustomEvent)firstDiscoEvt).customMessage(null); > > > > That means a global instance of 'DiscoveryCustomEvent' is being > > mutated outside discovery-spi infrastructure. It also means that > > discovery listeners receive 'DiscoveryCustomEvent' with 'null' field > > instead of 'CustomMessage' which they may rely on. > > > > Could someone confirm if it is wrong behavior and should be fixed? > > > > -- > > Best Regards, Vyacheslav D. > > > > -- > Best Regards, Vyacheslav D. >
