FtD Code Review Notes has been edited by Martin Ritchie (Mar 13, 2009).

(View changes)

Content:

Flow to Disk review points

ID Priority (H/M/L) Review Status
1 0.5 Removal of old get* Methods from TransactionLog  
2 0.5 Create Abstract BaseTransactionLog class to hold commonalities with existing TLogs  
3 0.5 Refactor Ref Counting out into BaseTransactionLog  
4 0.6 StoreContext update, initially to include the dequeue messageIds as per BDBStore  
5 0.6 StoreContext -> convert -> Transaction and use that for operation.(commit,abort...)  
6 0.6 Reference Count to use AtomicInts to reduce memory usage.  
7 0.5 Rename flow/recover -> unload/load Done
8 0.5 FlowableQueueEntryList extends QueueEntryList, but there are no unflowable lists, and there shouldn't be in the future either. (AS)
Done
9   Merge Inhaler/Purger threads to a single rebalance thread  
10   QueueEntryImpl allows direct access to the ContentHeader via the Filterable Interface, need an improved way of doing selectors that doesn't always require the message to be pulled from disk. Some checks can be done with data already in memory with QueueEntry; MessageID  
11   NoLocal requires message to be pulled in to memory.  
12   Linux ext3 means 31998 queues max per vhost per instance. as the dir is currently created even if it is not needed.  
13   getMessage contract broken MUST NEVER return null  
14   getMessage should do a load  
15   document reuse of setDelivered  
16   is load() thread safe

Testing

ID Priority (H/M/L) Test Status
1   What happens when the directory cannot hold any more messages, or queues.  
2   Test flowed queues delete backing store on close.  
3   Management Console Functionality, Viewing, Moving Messages  
4   Consuming from flowed queues with all ack modes : Client, Transacted, No-Ack  
5   Browsers with selectors. DONE
6   Selectors on normal consumer to be completed  
7   Test No_local on flowed queues : Currently flowed messages will be reloaded to check no_local values. Does it make sense to move them to the QueueEntry?  
8   Failure testing: What happens when disk runs out?  
9   Failure testing: Current implementation should log error and keep message in memory. Eventually though it will OOME the broker as it can't keep messages in memory.  
10   Testing on all supported OSes and File systems. Linux : ext3, SAN(vxfs); Solaris (ZFS); Windows NTFS?  
11   What happends if the disk fails/is removed?  

--------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]

Reply via email to