On 4 Jul 2010, at 17:51, Israel Lacerra wrote:
Using my strategy (create ReplicableCommand in CacheQueryImpl and then use RpcManager to broadcast the query), I'm having troubles getting the local Cache instance on each node. If I try to use CommandsFactory to initialize my replicableCommand, I create a undesired dependency: infinispan-core -> infinispan-query.
On the remote end, the Command is recreated using the following process:
1) The Marshaller framework is registered to use the ReplicableCommandExternalizer for all ReplicableCommands. This class has the knowledge of how to convert a stream of bytes to a ReplicableCommand on the remote end. ReplicableCommandExternalizer.readObject() will convert the stream into a command id + an array of object params.
2) ReplicableCommandExternalizer then passes this command id + params to RemoteCommandsFactory.fromStream(), which creates an *un-initialized* command, with params set (see javadocs on fromStream())
3) Before actually invoking the command, the InboundInvocationHandler *initializes* the command (injects the cache instance, component dependencies, etc) by calling CommandsFactory.initializeReplicableCommand(). See InboundInvocationHandlerImpl.handle() for details.
HTH
Manik
I need the Cache instance to get component registry and then get SearchFactoryImplementor to make the query.
Is there a way to get the local cache instance?
Someone has something to say about the way I'm solving it? Perhaps it's not the best way...
thanks!
Israel Lacerra
On Sat, Jun 19, 2010 at 9:31 PM, Israel Lacerra
<israeldl@gmail.com> wrote:
Ok! Understood.
So I'll try to use RpcManager to broadcast the query.
Thanks!
IsraelOn Fri, Jun 18, 2010 at 6:42 PM, Manik Surtani
<manik@jboss.org> wrote:
On 9 Jun 2010, at 05:45, Israel Lacerra wrote:
> Manik,
>
> About the "map" part of the map/reduce of ISPN-200.
>
> Looking in the code, my intention is(briefly) create a ReplicableCommand in CacheQueryImpl and then use RpcManager to make the query on all nodes.
>
> But ISPN-200 depends on ISPN-39, right?
Well, not precisely. They are related and a degenerate case of ISPN-39 *could* work for you, but isn't necessary. Let me explain:
ISPN-39 is about pushing tasks to nodes based on key. So, you may say something like, here's a task, T, which requires keys K1, K2, K3. The DistributionManager could then be used to determine the most appropriate node(s) to send T to, and process it there.
Now in the case of ISPN-200, you don't know which nodes contain the entries you are looking for. So you would need to broadcast the task, T, which in this case is a query task, to *all* nodes. So while it is similar to ISPN-39 in that it executes remote tasks, the logic of determining which nodes to execute the task on is different - you would need to execute the task on all nodes all the time.
Hope this clarifies things a bit. :)
Cheers
Manik
> This dependecy is about the map part? The idea behind ISPN-39 is to migrate a computation to other nodes? Like a "continuation"? And then ISPN-200 will use this api to make the query on all nodes?
>
>
> thanks!
>
> Israel
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev