The paging can disrupt the order of message delivery in the following way:

1. Starting a queue with fullSize=20, pageSize=10, downCacheSize=10
2. Sending 35 persistent messages (m0 to m34) to the queue
3. The JBM_MSG_REF table will look like this:

+------------------+----------+
| MESSAGE_ID | PAGE_ORD |
+------------------+----------+
| m0's id | NULL |
| .... | NULL |
| m19's id | NULL |
| m20's id | 0 |
| .... | 5 |
| m29's id | 9 |
| m30's id | NULL |
| .... | NULL |
| m34's id | NULL |
+------------------+----------+

No the order of messages in the table is exactly the same order as they were added to the in-memory queue, only
that m20 to m34 are paged and waiting to be loaded to the in-mem queue. Please note that messages m0 to m19 have
NULL page_ord because they are in-memory messages, messages m20 to m29 have non-null page_ord values because they
have been paged down to DB, messages m30 to m34 have NULL page_ord values because they are in the down cache and haven't
yet been written to DB.

If we at the moment shutdown and restart the server, the messages will be loaded from the DB in the same order as before.

But if we cosume a message (m19) before shutdown, it's possible that the table may look like this

+------------------+----------+
| MESSAGE_ID | PAGE_ORD |
+------------------+----------+
| m0's id | NULL |
| .... | NULL |
| m18's id | NULL |
| m20's id | 0 |
| .... | 5 |
| m29's id | 9 |
| m30's id | NULL |
| .... | NULL |
| m34's id | NULL |
+------------------+----------+

Now if we start the server again, it will load m0 to m18, plus m30 into the in-memory queue and update the paging status. The key sql statement is this

LOAD_UNPAGED_REFS=SELECT MESSAGE_ID, DELIVERY_COUNT, SCHED_DELIVERY FROM JBM_MSG_REF WHERE STATE = 'C' AND CHANNEL_ID = ? AND PAGE_ORD IS NULL ORDER BY ORD

This will cause m30 to be delivered before messages m20 to m29. So the order is broken.