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? 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. Dan _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
