| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
behaviour, the externalisation of the specs to follow, and a means to specify the internal_queue module to come.
|
| |
|
|
| |
when we are doing ack-only txns
|
| |
|
|
| |
txn consists only of acks, we do sync those acks in the qi (assuming the acks were on disk already); b) txns in non-durable queues never cause fsyncs, even if the messages are persistent (or the acks are for persistent messages); c) transactions which contain no publishes can now overtake txns which do contain publishes; d) txns which do not need to be sync'd in the qi can overtake those that do need to be sync'd in the qi (eg a txn with only acks for non-persistent msgs can overtake a txn with persistent publishes). The overtakings are all safe as commit is a sync operation on a channel, and can only overtake other txns, not other operations in general.
|
| |
|
|
| |
for them to enable us to tidy up after the process dies. The distinction between these monitors and the ones created in release_on_death is that the release_on_death ones are not stored in the client_mrefs dict, thus if a monitor DOWN message appears which we can't find in that dict, it is assumed it is a release_on_death monitor
|
| |\ |
|
| | |\ |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This doesn't change the meaning of the stanza with respect to temporary files.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
infinite loop. Fixed.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
disk but contained only references to transient messages then on restart, they would never be removed. Unfortunately, this does potentially introduce further work on startup (the queue will try to ensure that it loads the persistent contents of the first segment which contains a persistent message, which can involve scanning through a lot of segments. However, this is actually pretty quick. The only way to fix this would be to keep per segment counters of persistent messages and ensure that's written to disk too, but the extra code cost and complexity may make this just not worth it.
|
| | | |
| | |
| | |
| | | |
to be careful to unlink and ensure we have received any EXIT message generated
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
length. Note most expensive element in startup is loading in the msg_store index. Also note for some unexplained reason, this currently doesn't work with toke - the toke plugin will need reworking to become available to both msg_stores simultaneously.
|
| | | |
| | |
| | |
| | | |
shutdown cleanly, and all the clients that it previously knew about were also shutdown cleanly and found on startup.
|
| | | |
| | |
| | |
| | | |
state too, and init can be asked to attempt to recover previously saved index
|
| |\ \ \
| |/ / |
|
| | | | |
|
| | |\ \
| | |/
| |/| |
|
| | |\ \ |
|
| | | | |
| | | |
| | | |
| | | | |
in" pattern (gatherer.erl), and then make use of it when scanning queue indices and msg store files. Note the gatherer's exit signal was being caught in the handle_info of msg_store because trap_exits was on, hence moving that to later on in the msg_store init.
|
| | | | |
| | | |
| | | |
| | | | |
messages from the fhc, thus need to be able to process them. Also, that then requires that the fhc is started before the workers
|
| | | | |
| | | |
| | | |
| | | | |
populated and updated when file opening fails (eg enoent)
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Also fixed a bug which I'd sleepily introduced in vq:requeue where a msg_store:release had accidentally become a msg_store:remove (no idea how the tests managed to pass after that enough to convince me to commit - certainly had the tests failing today due to that one). Finally, persistent msgs in a non-durable queue should be sent to the transient msg_store, not the persistent msg_store. Thus they will survive a crash of the queue, but not a restart of the server.
|
| | | | |
| | | |
| | | |
| | | | |
into mnesia. Furthermore, it must be a call, not a cast otherwise it could be overtaken (though it returns first, and inits second). Note that this means on a collision, the queue may get > 1 init calls, hence need for idempotency, and the 2nd call may be delayed while the first init completes. Also note that the queue index init alters disk content. Thus initing the same queue with disk content concurrently will lead to unexpected results. However, this can't occur because durable queue recovery is the only time we are initing queues with disk content, and there will be no collisions at that point, so safe. In normal queue declaration collisions, there will be no disk content anyway.
|
| | | | |
| | | |
| | | |
| | | | |
indicies to occur in parallel (per queue). Also, queue creation can take some substantial time due to queue_index:init. Therefore, stagger the startup of a queue so that this potentially expensive step (a) doesn't get done at all if the queue already exists etc (b) doesn't block amqqueue_process:init from returning. Thus on startup now not only do we do the seeding of the msg_store in parallel (per queue), but the durable queues that come up can also do the bulk of their work in parallel, thus speeding recovery substantially.
|
| | | | | |
|
| |\ \ \ \
| | |_|/
| |/| | |
|
| | |\ \ \
| | |/ /
| |/| /
| | |/ |
|
| | | |
| | |
| | |
| | | |
though sadly only once they're completed
|
| | | |
| | |
| | |
| | | |
don't want the error msg when including the deps file when it doesn't exist, but at the same time we do want all errors if they occur when generating the deps. Hence -include is not permitted. Thus if we need the deps file then make it explicitly before including it.
|
| | | |\
| | |/
| |/| |
|
| | |\ \ |
|
| | | | | |
|
| | |\ \ \
| | |/ /
| |/| | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |\ \ \ |
|
| | | | | | |
|
| | |\ \ \ \ |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
through it.
|
| | | |_|_|/
| |/| | | |
|
| | |\ \ \ \
| | |_|_|/
| |/| | | |
|
