range_read times out because of false intervals:is_covered() use?

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Boot up a node.
2. Write the keys [a,b].
3. Run cs_api(_v2):range_read("a","b").

What is the expected output? What do you see instead?
Expected is the tuple {ok,[a,b]} in a short term. But instead I see 
{timeout,[a,b]} after ~config:read(range_read_timeout).

What version of the product are you using? On what operating system?
Latest SVN (659) on Ubuntu.

Please provide any additional information below.
When debugging, I can see that Done2 in cs_api(_v2):range_read_loop() is 
set to [all] as every Done2 will result in a list. But the 
intervals:is_covered(Interval, Intervals) seems not to respect the list 
[all]; although there is a case intervals:is_covered(_, all) -> true.

I didn't follow the intervals:is_covered function in the last case, which 
is the one used in this scenario, but I assume it handles the list [all] 
wrong.

Maybe a quick fix would be to introduce another function case:

intervals:is_covered(_, [all]) -> true.

Original issue reported on code.google.com by Uwe.Daue...@gmail.com on 30 Mar 2010 at 9:36

[GoogleCodeExporter]

is_covered is not the problem in this case:
true = intervals:is_covered(intervals:new(1,2), [all]).

The problem is that range_read works directly on the "ring data", i. e. the 
hashed
keys. "a" and "b" are items from the key space which are hashed to the ring 
space.
Additionally range_read doesn't take into account replication.

Original comment by schu...@gmail.com on 30 Mar 2010 at 12:15

• Changed state: Invalid

[GoogleCodeExporter]

Thanks Thorsten. Assuming I would use a Chord# Implementation and would not 
hash the 
keys, and would run the query cs_api(_v2):range_read("0a","0c"), then I should 
get 
correct result ({ok,[a,b]}) and without timeout. Is this correct?

Original comment by Uwe.Daue...@gmail.com on 30 Mar 2010 at 1:59