4:16 a.m.
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(a)gmail.com> wrote:
Ok! Understood.
So I'll try to use RpcManager to broadcast the query.
Thanks!
Israel
On Fri, Jun 18, 2010 at 6:42 PM, Manik Surtani <manik(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org