[infinispan-dev] HotRodMarshaller interface

[Galder Zamarreño]

At least for 1 and 2, I think it'd be good to keep in mind what Phillipe suggested in http://lists.jboss.org/pipermail/infinispan-dev/2010-February/005195.html

Basically, currently org.infinispan.marshall.Marshaller does too many things. At a global level it does:
- marshalling to/from streams
- marshalling to/from byte[]

Now, your suggestion to have a BasicMarshaller is the same that Phillipe did to have a ByteArrayMarshaller. IOW, have an interface for simply marshalling to/from byte[].

At least for 4.1, we could create the [Basic/ByteArray]Marshaller interface and have Marshaller inherit from it. For 5.0 we might want to have the stream marshaller as well so that Phillipe can find an easier way to add compression.

I can work on this myself since I know the marshaller API pretty well.

Wrt 3, I'm not so sure of the benefit of separating between marshalling a key (small) or value (large). At the marshaller level used to send stuff accross the cluster, we always use the same initial size, 128, and I don't recall seeing hot spot or anything around byte array resizing.

On Jul 8, 2010, at 3:57 PM, Manik Surtani wrote:

> Guys,
> 
> I just created ISPN-532 (HotRodMarshaller needs cleaning up) targeted for Radegast CR2 and Final.  I know it is late in the day to be making API changes in an interface, but I would much rather this is done right prior to being baked into Final and hence eternity.  :)
> 
> 	http://fisheye.jboss.org/browse/Infinispan/trunk/client/hotrod-client/src/main/java/org/infinispan/client/hotrod/HotRodMarshaller.java?r=1850
> 
> So I have 3 issues to address with this interface.
> 
> 1.  Methods on the interface
> 
> The purpose of this is simple: the 2 methods, readObject() and marshallObject() are meant to perform diametrically opposed tasks (byte[] -> object in one case, object -> byte[] in the other) but the names are far from that.
> 
> I propose either of the following:
> 
> 	1) readObject() and writeObject()
> 	2) Simply, read() and write()
> 	3) Or if we want to follow org.infinispan.marshall.Marshaller conventions, objectFromByteBuffer(), objectToByteBuffer()
> 
> My preference would be (3).
> 
> 
> 2.  Interface name and package
> 
> Further, any reason why we call this HotRodMarshaller?  Isn't it just a marshaller that serializes arbitrary objects <--> byte[] and should contain no HotRod-specific logic?  I can see why we did not use the org.infinispan.marshall.Marshaller interface for this (too complex?) but perhaps we could create a org.infinispan.marshall.BasicMarshaller which just contains objectFromByteBuffer() and objectToByteBuffer(), and Marshaller can extend BasicMarshaller for Infinispan's internals and HotRod clients can directly implement BasicMarshaller?
> 
> This would allow people who write custom marshallers to reuse them for both the HotRod client as well as for Infinispan's internal marshalling.
> 
> 3.  isKeyHint parameter on marshallObject()
> 
> What is this for?  And surely there is a more elegant/generic way to achieve this?  
> 
> Cheers
> Manik
> 
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache