Yakov, Sounds good. But there is a flaw in the procedure, that you described. If we have a TcpDiscoveryMetricsUpdateMessage in a queue, and a newer one arrives, then we will consider the existing one obsolete and won't process it. The newest metrics update message will be moved to the queue's tail, thus delaying the moment, when it will be processed. So, we may never come to a point, when an actual TcpDiscoveryMetricsUpdateMessage is processed. But if we replace an existing message with a newer one, and save the old position in a queue, then this approach will work. It will require a more complex synchronization, though, so it will still lead to some overhead.
How big the message worker's queue may grow until it becomes a problem? If it's 20 elements max, then linear time check is not that bad. BTW, RingMessageWorker#addMessage method checks for duplicating messages in the queue for some message types, including all custom discovery messages, which is done in linear time. Denis пт, 11 янв. 2019 г. в 00:54, Yakov Zhdanov <yzhda...@apache.org>: > Denis, what if we remove priority difference for messages and always add > new to the end of the queue? > > As far as traversing the queue - I don't like O(n) approaches =). So, with > adding all messages to the end of the queue (removing prio difference) I > would suggest that we save latest 1st lap message and latest 2nd lap > message and process metrics message in message worker thread in queue order > if they are latest and skip the otherwise. > > Does this make sense? > > --Yakov >
