Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
Staging was originally implemented so that a message with content that exceeds available memory can be handled. The message is sent to disk in parts as it arrives, and is never fully resident in memory. However, the current implementation of staging is problematic:
1. The current architecture requires the entire message to be loaded into memory before it can be delivered. This renders the staging facility superfluous. In fact, it can lead to a problem where it is possible to enqueue messages much larger than the available memory, but never be able to dequeue it again.
2. The current implementation uses a BDB database to save the message. This is done under a transaction to ensure atomicity of the operation. This results in two issues:
a) BDB is very slow for large messages, and gets exponentially slower as the message size grows.
b) The database leaves behind a large number of log files that are not currently managed and tend to accumulate.
The staging feature is still a valuable one, and the issue of reinstating staging should be revisited when the fundamental problem (1. above) has been corrected. The use of BDB is an implementation issue and can easily be changed for something more suitable.