[infinispan-dev] StateTransferControlCommand initialisation?

[Manik Surtani]

On 27 Mar 2009, at 17:39, Galder Zamarreno wrote:

>
>
> Manik Surtani wrote:
>> On 25 Mar 2009, at 19:23, Galder Zamarreno wrote:
>>> Hi,
>>>
>>> I'm looking at RemoteCommandFactory in Infinispan as part as mapping  
>>> the marshalling stuff to JBoss Marshalling and here's something  
>>> that has confused me:
>>>
>>> fromStream() method says:
>>>
>>> * Creates an un-initialized command.  Un-initialized in the sense  
>>> that parameters will be set, but any components
>>> * specific to the cache in question will not be set.
>>> * <p/>
>>> * You would typically set these parameters using {@link  
>>> org 
>>> .infinispan 
>>> .commands 
>>> .CommandsFactory#initializeReplicableCommand(ReplicableCommand)}
>>> * <p/>
>>>
>>> And then you do the following:
>>>
>>>        case StateTransferControlCommand.METHOD_ID:
>>>           command = new StateTransferControlCommand();
>>>           ((StateTransferControlCommand) command).init(rpcManager);
>>>           break;
>>>
>>> Shouldn't ((StateTransferControlCommand) command).init(rpcManager)  
>>> go into  
>>> org 
>>> .infinispan 
>>> .commands 
>>> .CommandsFactory#initializeReplicableCommand(ReplicableCommand).
>>>
>>> initializeReplicableCommand() javadoc says:
>>>
>>> * Initializes a {@link org.infinispan.commands.ReplicableCommand}  
>>> read from * a data stream with components specific to the target  
>>> cache instance.
>>>
>>> The rpcManager seems to be one those components?
>> No.  The RPCManager is scoped as GLOBAL:
>>    https://svn.jboss.org/repos/infinispan/trunk/src/main/java/org/infinispan/remoting/RPCManager.java 
>>  Refer to the @Scope annotation on the interface.
>> But I understand your confusion here.  We should either:
>> 1.  Change the Javadocs on fromStream() to be more explicit, i.e.,  
>> only dependent components of GLOBAL scope are injected.   
>> NAMED_CACHE scope components are only injected later with  
>> CommandsFactory.initializeReplicableCommand().
>> 2.  Remove the injection in fromStream(); have  
>> CommandsFactory.initializeReplicableCommand() handle all of the  
>> injection, of GLOBAL and NAMED_CACHE scoped components.
>> I have no problem with 2, if it makes your integration easier.  In  
>> fact, I actually think 2 is probably cleaner.
>
> I've looked into this and it looked simpler saying than actually  
> doing it. The problem here is that StateTransferControlCommand is  
> dealt in a very different way to the rest of ReplicableCommands that  
> extend CacheRPCCommand.

Ah, yes.

> CommandAwareRpcDispatcher.handle shows http://pastebin.com/m446036c4  
> and the problem is that perform() is called directly for  
> StateTransferControlCommand before any initialisation could be done.  
> That's why the RPCManager was set during unmarshalling.
>
> I still think that StateTransferControlCommand, being a  
> ReplicableCommand, should be allowed to go through  
> CommandsFactory.initializeReplicableCommand() but  
> CommandAwareRpcDispatcher.handle does not have access to command  
> factory and neither the global registry of components.

I suppose we then leave it such that global components are injected by  
the RemoteCommandFactory then, as it originally was?

>
>
> Ideally, I'd like to see something this being doable: http://pastebin.com/m3f403e2
>
> However, I dunno whether it's doable or make sense.
>
> Currently, CommandsFactory.initializeReplicableCommand() call  
> happens within InboundInvocationHandlerImpl.handle(CacheRPCCommand).
>
> Thoughts? I suppose I could always fallback on 1 but I don't like  
> different commands being treated in a different way. Ideally, all  
> replicable commands received would be instantiated in the  
> marshaller, and they would all be initialised in the same place.
>
>> Cheers
>> -- 
>> Manik Surtani
>> Lead, JBoss Cache
>> http://www.jbosscache.org
>> manik at jboss.org
>
> -- 
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat

--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik at jboss.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20090330/2a4e5b75/attachment-0001.html