[ 
https://issues.apache.org/jira/browse/IGNITE-28290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Steshin updated IGNITE-28290:
--------------------------------------
    Epic Link: IGNITE-25883

> Utility discovery collection message.
> -------------------------------------
>
>                 Key: IGNITE-28290
>                 URL: https://issues.apache.org/jira/browse/IGNITE-28290
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Vladimir Steshin
>            Priority: Major
>              Labels: IEP-132, ise
>
> While refactoring discovery messages to MessageSerializer, we should remove 
> _Serializables_ where possible. As much as we can. And use collections of 
> _Message_ for included messages (like 
> TcpDiscoveryNodeAddedMessage#msgs{_}){_} instead of collections of 
> _TcpDiscoveryAbstractMessage_ and _prepareMarshall()/finishInmarshall()_ for 
> them. However, the messages hierarchy and related dependencies often appear 
> not so trivial and hinder removing of _Serializable_ and/or 
> _prepareMarshall() / finishInmarshall()_ in a current ticket.
>  
> To get a message being refactored closer to the desired final design we might 
> have a message for holding a collection of discovery messages being able to 
> distinguish Serializable messages and not refactored  
> _TcpDiscoveryAbstractMessage._ And serialize them properly;
> Benefits:
>  * Storing/marking in one place messages that require post-refactoing of 
> serialization of included discovery messages collections. We have to do this 
> anyway.
>  * Avoiding MarshallableMessage only for 
> _prepareMarshall()/finishInmarshall()_ of messages collection which might not 
> yet be refactored to Message/MessageSerializer
>  * Removing Serializable off message classes even if this message might be 
> included in such a discovery message collection.
>  
> When the messages refactoring is done, we're going to remove this message.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to