[infinispan-dev] ClusteredGetCommand vs. SingleRpcCommand

[Radim Vansa]

I wasn't suggesting to remove CGC nor any others - haven't had any 
issues with that. Though, as I add another type of cache and compare 
that to distributed non-tx cache (looking for reusable code), I try to 
evaluate if any piece of code is really a proper behaviour, workaround 
or just technological debt. I haven't really checked the marshalling 
cost of CGC vs. SRC.

Following the pattern, I've created ClusteredGetAllCommand, too, but 
when Galder gets back to Functional API, he should properly implement 
the ReadOnly*Commands [1] and he'll need another command for that - or 
just push those functional commands through SingleRpcCommand.

So I take this as there's no trick in CGC.

R.

[1] https://issues.jboss.org/browse/ISPN-6586

On 05/18/2016 04:33 PM, Dan Berindei wrote:
> I wasn't present in the JBoss Cache days either, but I'm guessing it's
> to allow "special" processing of the command and/or results outside of
> the interceptor chain. It also saves a bit on the marshalling cost, as
> the serialization of SingleRpcCommand isn't terribly efficient.
>
> In general, I wouldn't want to force all commands to be
> VisitableCommands -- especially custom commands that our interceptors
> probably don't know how to deal with. And TransactionBoundaryCommands
> go through the chain, but they look up the transaction and create an
> invocation context based on it, and I'm not sure that logic would fit
> in SingleRpcCommand.
>
> But I remember how long it took me to get used to the back-and-forth
> between GetKeyValueCommand and ClusteredGetCommand, so I'm all for
> removing ClusteredGetCommand.
>
> Cheers
> Dan
>
>
> On Wed, May 18, 2016 at 3:12 PM, Radim Vansa <rvansa at redhat.com> wrote:
>> Just wondering, why do we have ClusteredGetCommand (and similar ones)
>> and don't wrap GetKeyValueCommand into SingleRpcCommand as with the
>> others? Git history starts in 2009, and I think this goes to real history :)
>>
>> Radim
>>
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss Performance Team
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team