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 performance impact of services serialization, since it doesn't happen too often.
There are some tests like *IgniteServiceConfigVariationsFullApiTest*, that check, that services, which are not serializable, can be successfully deployed. I think, these tests should be removed. It's reasonable to require serializability, since all *Services* are marked as *Serializable*, as I already mentioned. Slava and I discussed a possibility to choose a marshaller, depending on the node state. If a node is already connected to the cluster, then it could use a binary marshaller, otherwise JDK marshaller could be used. I think, if we decide to do so, then it will complicate logic and confuse users. This problem exists only for static services. They are not different from dynamic ones, except for the way of configuration, and a moment of deployment. I don't see, why different constraints should be applied to them. So, I'm for using the *JdkMarshaller* regardless of the service type or a node state. Denis пт, 7 дек. 2018 г. в 15:57, Vyacheslav Daradur <daradu...@gmail.com>: > 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' because class can't be registered in > MarshallerContextImpl#registerClassName -> transport.proposeMapping on > account of the request which can't be sent through discovery-spi at > the moment. > > Also, 'JdkMarshaller' can't be used because it imposes limits on > objects that should implement 'Serializable' interface. But this > restriction is unacceptable for the case. > > As a workaround solution, an external library, like KRYO, can be used. > > What tools also available in the project to solve this problem? > > -- > Best Regards, Vyacheslav D. >
