1

I may be approaching this all wrong, but I would like to use a REDIS bitmap to track activity within my application. I have a piece of code like the following:

 using (var conn = new RedisConnection("localhost"))
        {
            conn.Open();

            var b1 = conn.Strings.SetBit(1, "test:2012-07-25", 1, true);
            conn.Wait(b1);

            var b2 = conn.Strings.SetBit(1, "test:2012-07-25", 3, true);
            conn.Wait(b2);


            var arr = conn.Strings.Get(1, "test:2012-07-25");
            conn.Wait(arr);


            BitArray bits = new BitArray(arr.Result);

        }

I can add entries (b1 & b2) without any issue. However, when I attempt to get the bitmap back from the server as a bitarray it does not work correctly (I get a value but the bits that are set are completely incorrect). I assume I am doing something wrong in using the Strings.Get function to attempt to return the bits, but I don't know how else to go about it. The only obvious way to do it would be to make individual calls to getbit for each date I am interested in, but this would seemingly introduce a significant amount of round-trips to the server. Any help would be appreciated!

JP.
  • 5,536
  • 7
  • 58
  • 100

1 Answers1

1

Sorry folks, the correct result is being returned, I was reading it wrong. There are really two gotchas:

  • The bits are written from right to left. When a byte is returned it will essentially be in the reverse order of what is expected (expected by me at least). So in the above examble. I was sent back a byte that looked like this (the reverse of what I expected)

[0] false [1] false [2] false [3] false [4] true [5] false [6] true [7] false

  • You need to read in order of bytes. Byte 0 will contain the first 8 bits, 1 the next set of bits, ad infinitum. This is only important to note because of the bit reversal mentioned in point #1. If, in my original example, i had set offset 10 to true in Redis, this would show up in bit position 13. This is because offsets (bits) 0-7 are stored in the first byte and offsets 8-15 are stored in the second byte. Offset 10 is the 3rd stored in the second byte, and since it's reverse we count back from 15,14...13

I guess the key is actually to reverse the bytes/bits before processing...Hope this helps someone out in the future...

JP.
  • 5,536
  • 7
  • 58
  • 100
  • 1
    I'm glad you found the answer, but bit-indices are pretty much **always** written right-to-left. That way, bit 0 is the LSB, regardless of how long it ends up – Marc Gravell Jul 24 '12 at 21:01
  • @MarcGravell Thanks for the feedback. I guess it really only matters when the index is meaningful such as in the following example where index is used to reflect user_id. Does that make sense or am I missing something? http://blog.getspool.com/2011/11/29/fast-easy-realtime-metrics-using-redis-bitmaps/ – JP. Jul 24 '12 at 21:06
  • Oh, right, I think I see. Tell you what, leave that with me. I'm not at a PC tonight, but tomorrow I'll check whether all is well or not. – Marc Gravell Jul 24 '12 at 21:19
  • Thanks @MarcGravell I look forward to hearing your thoughts and appreciate your help! – JP. Jul 24 '12 at 21:30