Hi, Some thought on ReplicateCommand. It is also used to replicate a single command, which is inefficient, as 2 objects are unnecessarily created: the ReplicateCommand itself and an array holding only one object. Why not replicated the aggregated command directly?

Another thing about the name: even though it is correct, it sounds very much like ReplicableCommand. I suggest renaming to CompositeCommand, or ContainerCommand. wdyt?

Manik Surtani wrote: > > On 31 Mar 2009, at 11:16, Mircea Markus wrote: > >> Hi, >> >> Some thought on ReplicateCommand. >> It is also used to replicate a single command, which is >> inefficient, as 2 objects are unnecessarily created: the >> ReplicateCommand itself and an array holding only one object. >> Why not replicated the aggregated command directly? > > The actual command is replicated directly. See > ReplicateCommand.getParameters(). There is just an extra int in > the byte stream containing the number of commands contained. There still are two built objects being built, ReplicateCommand and the aggregated ReplicableCommand[], that's my concern. Re:getParameters, I see that there is an array built in that command, which contains the param list. what about creating an array pool, and pass them to the command, i.e. the signature would be: getParameters(Object[] params)?

> >> Another thing about the name: even though it is correct, it sounds >> very much like ReplicableCommand. I suggest renaming to >> CompositeCommand, or ContainerCommand. >> wdyt? > > Agreed about the name. Don't like CompositeCommand or > ContainerCommand though, they both suggest a command that holds > other commands. That is not this command's primary purpose. It's > primary purpose is to "transport" a command across a network and > execute the command on a remote cache. Yep, see your point re: composite. > > So, the interface it implements is more appropriately named > (CacheRPCCommand). Perhaps there should be 2 separate > implementations, SingleRPCCommand, MultipleRPCCommand? > > > -- > Manik Surtani > Lead, JBoss Cache > http://www.jbosscache.org > manik(a)jboss.org <mailto:manik@jboss.org> > > > >

>>> >>> So, the interface it implements is more appropriately named >>> (CacheRPCCommand). Perhaps there should be 2 separate >>> implementations, SingleRPCCommand, MultipleRPCCommand? <mailto:manik@jboss.org> Why do we need the SingleRPCCommand? Can't we replicated the aggregated command directly?

On 31 Mar 2009, at 11:16, Mircea Markus wrote: > Hi, > > Some thought on ReplicateCommand. > It is also used to replicate a single command, which is inefficient, > as 2 objects are unnecessarily created: the ReplicateCommand itself > and an array holding only one object. > Why not replicated the aggregated command directly? The actual command is replicated directly. See ReplicateCommand.getParameters(). There is just an extra int in the byte stream containing the number of commands contained. > Another thing about the name: even though it is correct, it sounds > very much like ReplicableCommand. I suggest renaming to > CompositeCommand, or ContainerCommand. > wdyt? Agreed about the name. Don't like CompositeCommand or ContainerCommand though, they both suggest a command that holds other commands. That is not this command's primary purpose. It's primary purpose is to "transport" a command across a network and execute the command on a remote cache. So, the interface it implements is more appropriately named (CacheRPCCommand). Perhaps there should be 2 separate implementations, SingleRPCCommand, MultipleRPCCommand?

-- Manik Surtani Lead, JBoss Cache http://www.jbosscache.org manik(a)jboss.org ------------------------------------------------------------------------ _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev