AIO Callbacks versus Ordering...

[clebert.suconic]

libaio won't guarantee ordering over the callbacks. (That's a clear fact already, confirmed with the kernel developers some time ago)

So because of that I'm having issues with ordering and AIO. (I believe that's one of the reasons we were blocking before).

And I'm not having the same issues with NIO, since NIO provides correct ordering

To fix that I will need some efficient Collection that would hold the callbacks and flush them in order, given an ID that I could add to the callbacks.

Any ideas?

[clebert.suconic]

Basically what I need is something with this interface:

interface Orderer
{
 public void doCallback(long id, Runnable callback);
}

And if I call this:

 Orderer ord = new OrdererImpl();
 ord.doCallback(2, new Runnable() {... System.out.println(2)...}
 ord.doCallback(4, new Runnable() {... System.out.println(4)...}
 ord.doCallback(3, new Runnable() {... System.out.println(3)...}
 ord.doCallback(1, new Runnable() {... System.out.println(1)...}

I would see this output


1
2
3
4

[timfox]

libaio won't guarantee ordering over the callbacks. (That's a clear fact already, confirmed with the kernel developers some time ago)

So because of that I'm having issues with ordering and AIO. (I believe that's one of the reasons we were blocking before).

And I'm not having the same issues with NIO, since NIO provides correct ordering

To fix that I will need some efficient Collection that would hold the callbacks and flush them in order, given an ID that I could add to the callbacks.

Any ideas?

I don't understand why you want ordering.

Currently, with blocking, we don't have any guarantees about which thread will unblock first, since, as you say AIO doesn't guarantee ordering, so the order the responses go back to the client is *currently* undefined.

I don't see that's any different.

Can you explain in more detail where this extra requirement of ordering came from?

[clebert.suconic]

Before the AIO callbacks were only being used to guarantee responses, and feed the Latch.

Now the add to the queue, and response to the users is made on the Callback. (So we would be able to only add and respond to client when both replicated and persisted).

The persistence callback is coming out of order, and hence the add to the queue is being added out of order.

So far I could only see this case with a producer and block = false.

I will debug a little more to make sure about my conclusions.