In terms of providing consistency of services' API, where the
interface `Service` extend `Serializable` end-user should make his
implementation to be serializable properly.
>From this point of view, `JdkMarshaller` can be used as the common
marshaller for service's instance, this allows reduce
A bit more:
I implemented a solution which regards a node connection state: if the
node already joined to the cluster, then configured marshaller will be
used, otherwise, JdkMarshaller will be used.
This affects static configurations if a service can't be serialized
this will be logged (covered
Denis, thank you for the answer.
I've already implemented the same approach. It works well, new and old
tests have passed.
On Wed, Dec 12, 2018 at 3:47 PM Denis Mekhanikov wrote:
>
> Slava,
>
> Interface *Service *extends *Serializable.* So, all services are supposed
> to be serializable by the
Slava,
Interface *Service *extends *Serializable.* So, all services are supposed
to be serializable by the JdkMarshaller.
Usage of *BinaryMarshaller* or *OptimizedMarshaller* makes sense only from
performance point of view.
But I don't think, that we should try too hard to minimize the
Igniters, I need your advice about the following problem:
It is necessary to serialize an object (just convert an object to
bytes array) for including it in joining node data (DiscoveryDataBag)
*at node startup routine*.
The marshalling hangs If we use 'BinaryMarshaller' or
'OptimizedMarshaler'
