| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
| |
lists are more pleasant than sets in APIs, plus in our use we have a
list to start with.
|
| |
|
|
|
|
|
|
|
| |
The main motivation is to reduce the memory and on-disk footprint of
the guid from ~34 bytes to 16. But it turns out that this actually
results in a speed improvement of a few percent as well, even for
non-persistent messaging, presumably due to the memory management
effects and the fact that 16 byte binaries are easier to copy between
processes than the deep(ish) original guid structure.
|
| | |
|
| |
|
|
| |
since we prune more than just mnesia
|
| | |
|
| |
|
|
|
| |
giving it a name that describes what it does, and extracting recursion
vestiges into caller.
|
| |
|
|
|
| |
This is just a renaming exercise, but it turns rabbit_msg_store into
a general purpose message store.
|
| | |
|
| |
|
|
| |
rabbit_mixed_queue and rabbit_disk_queue see guids, not non_neg_integers.
|
| |
|
|
| |
thus further generalising rabbit_msg_file
|
| |
|
|
|
|
| |
it's not used anywhere and was cluttering the api
Also, make type sigs more meaningful and do not include rabbit.hrl,
thus underlining the general nature of this module.
|
| |
|
|
| |
The msg_store knows nothing about queues, or message structure.
|
| |
|
|
| |
to match what we call the containing table
|
| |
|
|
| |
to match what we call the containing table
|
| |
|
|
| |
vaporise was wiping out the disk_only data (both as a file, and when it was in mnesia). The result was that if the dq was in disk_only mode before being vaporised, it would refuse to start up again. Thus vaporise now pushes the queue back to ram_disk mode if necessary, after wiping out the contents of the mnesia table. Finally, all tests pass again.
|
| |
|
|
| |
heavily loaded - up the limit to 5 seconds. However, I suspect something like 60 seconds is more likely to be realistic value
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is slightly grim because I have to store some values in the mnesia table which then have to survive all the start up logic, so there are a couple of annoying 1-line changes elsewhere. However, it does indeed work.
There was also one bool() -> boolean() fix in the memory_manager.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
vaporise - hopefully sufficiently that both Matthias and I are happy with the result\000
|
| |
|
|
| |
between queues being deleted and new queues with the same name being created and published to
|
| |
|
|
| |
Tested by deliberately breaking the compaction in a variety of ways and then coverage and startup and ensuring the correct code paths are taken.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
available tokes. In extremis, when available tokens is 0, this makes queues very likely to switch mode (bad, memory is tight), and when there are lots of tokens available, this makes queues less likely to switch mode (bad, memory is plentiful). Instead, we should be using constant offsets, based on the total number of tokens in the system.
|
| |
|
|
| |
initial calls to report_memory
|
| |
|
|
|
|
| |
disk already and was then told to go to disk_only mode, it would form a single requeue_next_n call, where the N would be the length of the queue. This would be detected by the disk_queue and become a no-op. Because of the introduction of the magic_marker_msg, that is no longer possible - we want the marker to go from the back of the queue to the front. As such, the N will at most be 1 less than the queue length, causing unnecessary work to be done.
This patch removes unnecessary work by observing that we do not need to rotate the entire queue should we find that the queue consists of zero or more disk-stored msgs followed by zero or more ram-only stored messages. If this is the case, we only need to publish the latter ram-only messages, and have no need for the magic marker msgs at all. Furthermore, if there are no ram-only messages we have no work to do at all. The only situation in which we must rotate the entire queue is when we have ram-only messages followed by disk messages. In this case, we have to get the ram-only messages onto the disk queue before the disk messages, which requires the full rotation.
|
| |
|
|
| |
and one change so that rmf:read returns the MsgId off disk to be later matched. This is purely defensive.
|
| |
|
|
| |
The details of how messages are encoded in files are opaque to disk_queue.
|
| |
|
|
| |
This was added in revision b48919ed4e12 for no apparent reason
|
| |
|
|
|
|
|
|
| |
The details of the message packing are opaque to high level code, as
they should be. The TotalSize that code sees now is the total size of
the message on disk, including all packing adjustments, which is all
that is ever needed to perform all the necessary file positioning etc
at that level.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This allows us to replace the last remaining file:open with open_file.
Also, extract binary mode settings and use them in both open_file and
fh cache creation.
|
| | |
|
| |
|
|
| |
accidentally changed in previous commit
|
| | |
|
| | |
|
| | |
|