Hello Antonio, You can solve this by removing all types from the static BinaryConfiguration, and rely on dynamic type registration instead.
In most cases, you don't need to do anything extra and types will be registered automatically on first use (e.g. cache.put call). If you still encounter an edge case where a type can't be resolved, you can force the type registration like this: ignite.binary().type(MyClass.class) https://ignite.apache.org/docs/latest/data-modeling/data-modeling On Tue, Nov 30, 2021 at 4:09 PM Rotondi, Antonio < antonio.roto...@credit-suisse.com> wrote: > Hello, > > I have a question regarding an application we have already in production > and for which we are trying to clean as much as possible the dependencies > between server node and client node ones resources. > > In particular we are seeing that it is not possible to set the binary > types configuration in the server cluster configuration without adding that > to all client nodes cluster configuration as well. This is a rather > annoying dependency to manage as it will force the redeployment or patching > of all the client nodes when a new type is added to the cache (think > microservices) . > > I could not find a way to circumvent that as the client needs to connect > tot the gird before it can call a remote task to pull the binary types > configuration and the client will fail to start ignite with an error > stating a difference between the server and client binary type > configuration. > > This server resources dependencies in the client seems to be a general > issue across the whole Ignite architecture, especially because > configuration related ones are not included in class peer loading. > > > > Many thanks for any advise anyone can give me. > > > > Best regards, > > Antonio > > > > > =============================================================================== > Please access the attached hyperlink for an important data protection > disclaimer: > https://www.credit-suisse.com/uk/en/legal/privacy-statement.html > If you have received any marketing or product promotion communications in > this > email, you can unsubscribe from receiving such communications by > contacting the > sender of this message or your regular Credit Suisse contact. > > =============================================================================== > > > ============================================================================== > Where required by law, and except for FX instruments, pre-trade mid-market > mark > is the arithmetic mean of bid and offer prices unless otherwise stated; > other > regulatory disclosures are at https://plus.credit-suisse.com > > ============================================================================== > > > ============================================================================== > Please access the attached hyperlink for an important electronic > communications disclaimer: > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > > ============================================================================== >
