java_api: node responsible for a key

[Rebeca Schroeder Freitas]

Hello,

I'd like to find the node responsible for a key or if a specific node is responsible for a specific key. Is there a way to do that through the java api?
What about using the doRPC method in de.zib.scalaris.Connection class? In this case, which module and function I should call?

[Nico Kruber]

Hi Rebeca,
Unfortunately, there is no such function in our Java or Erlang APIs.

It would however go into the api_dht_raw erlang module. If you look into that,
you'll find that there is an unreliable_lookup/2 function which sends a
message to the dht_node responsible for a given key.
A simple message handler in the dht_node would be able to reply with the
information you may need. You could for example send a message like this:

Msg = {get_node_details, comm:this(), [node]}

and then receive it with:

receive {get_node_details_response, [Node]} -> Node
end

There remains the problem that the message may get lost and you'll never
receive an answer. If you use a timeout in that receive, be sure to tag the
message with comm:reply_as/3 or you may receive old messages.
From Java, you would then of course use the doRPC method in order to call the
one you export from erlang just like the rest of our API.


May I ask, what you need that functionality for? You can't really do anything
useful with this information through our APIs at the moment...


Regards,
Nico

[Rebeca Schroeder Freitas]

Hi Nico,

Thanks for your help!

Actually, I'm carrying out an experiment using a specific data fragmentation method and I would like to know if a transaction could run locally or how many nodes are required in a distributed execution.

Best regards,
Rebeca

[Nico Kruber]

If you want to get the nodes responsible for (client) keys, please be aware,
that the lookup message I gave you works on (internal) hashed keys.
In the erlang API you can use api_dht:hash_key(client_key()) -> ?RT:key() for
converting your client keys, i.e. strings.
In rt_chord these hashed keys are represented by integers but you don't need
to care, just put it into the lookup.

Also be aware that we store items on 4 replicas and you can use the following
methods to get the hashed keys:
api_rdht:get_replica_keys(client_key()) -> [?RT:key()].
api_dht_raw:get_replica_keys(?RT:key()) -> [?RT:key()].


Nico