[
https://issues.apache.org/jira/browse/IGNITE-28290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-28290:
--------------------------------------
Description:
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.
was:
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.
> 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)
