Re: [infinispan-dev] @Externalize in conjunction with Infinispan?

Do we also want to give end-users the option of pre-registering externalizers so that they can take advantage of (even) smaller payloads using a short identifier for externalizer ID?

On 29 Mar 2011, at 08:24, Galder Zamarreño wrote: > > On Mar 28, 2011, at 3:50 PM, David M. Lloyd wrote: > >> On 03/28/2011 03:53 AM, Galder Zamarreño wrote: >>> Hey David, >>> >>> I'm gonna start looking into @Externalize this week and I was >>> wondering whether we'll be able to use it as is with Infinispan? >>> >>> I mean, we have our own Externalizer interface which then maps to a >>> JBMAR Writer class via an adapter. This adapter is what makes a >>> Writer use our own Externalizer.writeObject(). The reading part is >>> done via an implementation of ObjectTable.readObject() where we map >>> an Id that's written by each of our Externalizer implementations to >>> the corresponding Externalizer so that it can read the object. >>> >>> I get the feeling that the way we use JBMAR might not suit the way >>> you can ship externalizer classes around to unmarshall stuff? >> >> The Externalizer interface and the @Externalize annotation rely on a different mechanism than object tables. You set up the AnnotationClassExternalizerFactory as your class externalizer factory in the configuration and the annotation will be recognized. >> >>> Also, in JBMAR, how does the marshaller side know that it does not >>> need to send the externalizer class again? I ask this cos you'd only >>> want the Externalizer class to be sent once to the receiving end, and >>> only if it's not aware of it? Or does it do it for all nodes in the >>> first request? >> >> It always sends the externalizer instance once for each externalizer. If you send the same externalizer twice, it will of course use a very compact backreference. The size of this initial message is dominated by the length of the class name, unless for some reason you use a complex externalizer. >> >>> Finally, if we can't take advantage of JBMAR to do this for us, how >>> much work do you think it would take to implement something similar >>> at the Infinispan level? >> >> Well ultimately the problem boils down to, how will you communicate which externalizer to use between sender and recipient. Using JBMAR Externalizers is the most simple and flexible option, however writing the class name can consume substantially more space than, say, an integer or a short. That said, the cost disappears into larger messages. The downside of using an integer or short however is that you have to preallocate and/or coordinate the identifier space. >> >> So I guess I don't really have an easy answer. Externalizers are simple but use a little more space. Using numeric IDs are somewhat more difficult (especially for end-users) but use less space. > > Thanks David, your reply made me see it clearly. > > In fact, I think we'll end up using the two methods. For internal and framework developers, the current set up works nicely. No annotations, so they can abstract Infinispan externalizers easily and we have very small payloads which is very efficient. Remember that I originally tried your Externalizer interface but the end result were payloads that were a bit big for our liking. That's how I ended up with the current set up. > > However, for the end user, or average Joe, your Externalizer might be more useful because it uses annotations and needs no pre-registration. So, much easier to use at first glance though some bigger payloads. > > CC'ing the infinispan-dev list. > >> >> -- >> - DML > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev