-- Galder Zamarreño Infinispan, Red Hat > On 19 Jun 2017, at 13:17, Dan Berindei <dan.berin...@gmail.com> wrote: > > On Fri, Jun 16, 2017 at 1:07 PM, Galder Zamarreño <gal...@redhat.com> wrote: >> >> -- >> Galder Zamarreño >> Infinispan, Red Hat >> >>> On 15 Jun 2017, at 15:25, Adrian Nistor <anis...@redhat.com> wrote: >>> >>> Galder, I've seen AddProtobufTask in March or April when you mentioned this >>> issue on the devlist; that approach can work for protostream marshallers or >>> any other code bits that the Cache does not depend on during startup, and >>> which can be deployed anytime later. In this category we currently have : >>> filters, converters. These are currently deployed with the help of a >>> DeploymentUnitProcessor, but we could have done it using a ServerTask as >>> well. >> >> ^ I'm not sure we had ServerTasks in place when we had filters and >> converters... But if we had server tasks then, we should have used that >> path. My bad if we didn't do it :\ >> >>> Now that we took the route of DUP, I think we should continue in a >>> consistent manner and use it for other 'deployables' we identify from now >>> on, ie. the protobuf entity marshallers. >> >> ^ Having written DUPs, I consider them to be a royal PITA. So, I'm against >> that. >> >>> As for encoders, lucene analyzers, compatibility marshaller, event >>> marshaller - these are all needed during cache startup. We need to come up >>> with something for these, so I propose to look them up using the >>> "moduleId:slot:className" convention. >> >> As I see it, encoders/compatibility-marshaller/event-marshaller might not be >> needed on startup. If data is kept in binary and only deserialized lazily >> when needed, you only need them when you're going to do what you need... >> > > What if you start a node and a client immediately tries to register an > even listener?
If the event listener server side requires any deserialization, I'd expect the node on startup to have a way to load the encoder to be used, either via config or a server tasks that's deployed by the user or pre-registered by the server. > > Not sure about the others, but for the lucene analyzers, I assume some > configurations will have to analyze/index entries that we receive via > state transfer during startup. Good point. This is a use case where unmarshalling/deserialization/decoding would be required on startup, to be able to index data. > > Dan > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev