PATCH: FlatQueueStrategy.GetTimeoutMessages

[tyler.burd]

In the current trunk the FlatQueueStrategy.GetTimeoutMessages was
stubbed with a simple "yield break;". I just uploaded a patch that
adds what I believe to be the correct logic to the method. Most was
copied from the SubQueueStrategy, changing "SubQueue" to
"SiblingQueue" where necessary. I did add some logging, as I needed
to know info bout the timeout messages that are restored from the
queue.

I do have an informal "review" of RSB and its architecture in the
works, by the way. I just need quite a bit of time to review and
experiment with all of its features.

-tyler

[tyler.burd]

I uploaded a revised version of the patch that fixes bugs in both the
FlatQueueStrategy.GetTimeoutMessages AND the
SubQueueStrategy.GetTimeoutMessages methods.

The SubQueueStrategy.GetTimeoutMessages method was deserializing the
DateTime to be sent via the following line:
Time = DateTime.FromBinary(BitConverter.ToInt64(message.Extension, 0))

I was having all kinds of weird dates show up when the messages were
restored from the queue, and I discovered it should actually be this:
Time = DateTime.FromBinary(BitConverter.ToInt64(message.Extension,
16))

Notice the change from "0" to "16". This is because the first 16
bytes of the message.Extension property are set to the message id in
the MsmqTransport.GenerateMsmqMessageFromMessageBatch method. I have
verified that my changes restore the _correct_ times to be sent.

Let me know your thoughts. Thanks!
-tyler