Alex, this will require some more coding. The difference between nodes and custom messages is that node can easily be identified by ID, but messages now do not have such strong IDs and is pretty hard to compare them in general case. However, this is, of course, possible.
--Yakov 2017-02-03 19:32 GMT+07:00 Alexey Goncharuk <alexey.goncha...@gmail.com>: > I think we should have duplicate filtering logic in discovery manager. As > far as I remember, we wanted custom events to be consistent with other > discovery events and we rely on the fact that node joined and node left > event won't be received twice. > > > > 2017-02-03 14:40 GMT+03:00 Sergey Chugunov <sergey.chugu...@gmail.com>: > > > Yakov, > > > > Thanks for clean explanation, also I found exactly that logic in > > RingMessageWorker code. > > > > But I strongly believe that this behavior should have been documented in > > *DiscoveryCustomMessage* interface (I think it is the best place for > this). > > > > Messaging managers like discovery manager must provide very explicit and > > detailed documentation for guarantees they provide to their users so > > developers wouldn't guess what to expect. > > > > Anyway modifying my protocol for IGNITE-4302 is not a big deal, I can > > easily change it to handle situations of like this. > > Also as part of the JIRA I'll try to clarify documentation at least for > > this case. > > > > Thanks, > > Sergey. > > > > On Fri, Feb 3, 2017 at 1:30 PM, Yakov Zhdanov <yzhda...@apache.org> > wrote: > > > > > Can anyone point a place in javadoc that states that there is exactly > > once > > > guarantee? > > > > > > Imagine you have nodes A, B and C. A sends custom message to B and gets > > ack > > > back, B sends to C and dies. A connects to C and resends the message. > > > Result - C has got the message twice. Currently handling logic is > > > responsible for resolving duplicates. > > > > > > --Yakov > > > > > >
