summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Merge in defaultSimon MacMullen2014-01-0713-637/+840
|\
| * Merge bug25935Simon MacMullen2014-01-071-1/+10
| |\
| | * Accept this from federation.Simon MacMullen2014-01-071-1/+10
| |/
| * stable to defaultSimon MacMullen2014-01-070-0/+0
| |\
| | * Merge bug25945 againSimon MacMullen2014-01-071-1/+3
| | |\
| | | * Uh, that function needs another headerSimon MacMullen2014-01-071-1/+3
| | | |
| * | | Merge bug25938Simon MacMullen2014-01-073-353/+503
| |\ \ \
| | * | | Multi-headsSimon MacMullen2014-01-071-6/+4
| | | | |
| | * | | Fix handling of credit arriving with drain=true and an empty queue - we need ↵Simon MacMullen2014-01-072-9/+13
| | | | | | | | | | | | | | | | | | | | to not really add the credit (since it is "used up" immediately and thus not unblock if needed).
| | * | | Merge in defaultSimon MacMullen2014-01-075-112/+127
| | |\ \ \ | | |/ / / | |/| | |
| * | | | Stable to defaultSimon MacMullen2014-01-0716-272/+431
| |\ \ \ \ | | |_|/ / | |/| | |
| | * | | Merge bug 25943Simon MacMullen2014-01-071-40/+34
| | |\ \ \
| | | * | | cosmeticMatthias Radestock2014-01-031-6/+5
| | | | | |
| | | * | | lift buffer vars from stateMatthias Radestock2014-01-031-36/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This improves performance by reducing state update and also makes it clear that these vars are only updated in the two loop functions.
| | | * | | merge bug25939 into bug25943Matthias Radestock2014-01-031-23/+41
| | | |\ \ \
| | * | \ \ \ Merge bug25939Simon MacMullen2014-01-061-23/+41
| | |\ \ \ \ \
| | | * | | | | Simplify binlist_split from /4 to /3.Simon MacMullen2014-01-061-6/+6
| | | | |/ / / | | | |/| | |
| | | * | | | become 1.0 with the correct stateMatthias Radestock2014-01-021-2/+7
| | | | | | |
| | | * | | | eliminate unnecessary state modificationMatthias Radestock2014-01-021-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | amazingly this actually yields a few % performance improvement
| | | * | | | further optimise frame readingMatthias Radestock2014-01-021-21/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Handle complete frames in one go, if possible, rather than header and payload separately. This essentially halves the amount of binary splitting in the framing code. Note that we only do this when the buffer contains just one binary. Tests have shown that attempting to introduce this optimisation when the buffer comprises multiple binaries hurts performance for large messages. That's presumably because we end up constructing larger intermediate binaries.
| | | * | | | merge stable into bug25939Matthias Radestock2014-01-011-6/+17
| | | |\ \ \ \ | | | | |/ / / | | | |/| | |
| | | | * | | refactor: better var namesMatthias Radestock2013-12-271-4/+4
| | | | | | |
| | | | * | | restore short message performanceMatthias Radestock2013-12-271-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | it turns out that short message performance had actually gotten worse, but this was masked by the scheduler.
| | | | * | | more efficient data splitting in readerMatthias Radestock2013-12-251-6/+12
| | | | | | |
| | * | | | | Merge bug 25942Simon MacMullen2014-01-0616-175/+323
| | |\ \ \ \ \
| | | * \ \ \ \ stable to defaultSimon MacMullen2014-01-062-2/+2
| | | |\ \ \ \ \
| | | * \ \ \ \ \ merge stable into defaultMatthias Radestock2014-01-0115-173/+321
| | | |\ \ \ \ \ \ | | | | |_|/ / / / | | | |/| | | | |
| | * | | | | | | some small codec optimisationsMatthias Radestock2014-01-022-46/+45
| | |/ / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - encode and decode field types as characters rather than strings - construct shallower iolists by cons'ing instead of appending - avoid construction of intermediate binary for tables and arrays
| * | | | | | | Merge bug25945Simon MacMullen2014-01-070-0/+0
| |\ \ \ \ \ \ \ | | | |_|/ / / / | | |/| | | | / | | |_|_|_|_|/ | |/| | | | |
| * | | | | | Notify on channel down.Simon MacMullen2014-01-071-0/+10
| |/ / / / /
| * | | | | Merge bug25928 againSimon MacMullen2014-01-062-2/+2
| |\ \ \ \ \ | | |/ / / / | |/| | | |
| | * | | | Revert the changes to the error thrown.Simon MacMullen2014-01-062-2/+2
| | | | | |
| * | | | | simplifyMatthias Radestock2014-01-011-2/+2
| | | | | |
| * | | | | small refactor: simplify AMQP version negotiation a little bitMatthias Radestock2014-01-011-13/+15
| | | | | |
| * | | | | correct typo in commentMatthias Radestock2014-01-011-1/+1
| | |_|/ / | |/| | | | | | | | | | | | | This was introduced in http://hg.rabbitmq.com/rabbitmq-server/rev/4852382b462b
| | | | * move consumer_use calculations into rabbit_queue_consumersMatthias Radestock2014-01-062-49/+51
| | | | |
| | | | * refactor: prepare for more stateMatthias Radestock2014-01-061-36/+45
| | | | |
| | | | * refactor: better var nameMatthias Radestock2013-12-242-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | DeliverFun wasn't deliverying anything. It was just getting hold of a message *to* deliver. -> FetchFun
| | | | * specsMatthias Radestock2013-12-241-4/+48
| | | | |
| | | | * refactor: re-order and re-nameMatthias Radestock2013-12-241-65/+64
| | | | |
| | | | * merge default into bug25938Matthias Radestock2013-12-242-308/+410
| | | | |\ | | | |/ /
| | | | * reduce distance to defaultMatthias Radestock2013-12-241-1/+1
| | | | | | | | | | | | | | | | | | | | this got lost in the merge
| | | | * cosmeticMatthias Radestock2013-12-241-1/+1
| | | | |
| | | | * merge default into bug25938Matthias Radestock2013-12-240-0/+0
| | | | |\
| | | | * | oopsMatthias Radestock2013-12-231-1/+1
| | | | | |
| | | | * | cosmeticMatthias Radestock2013-12-231-1/+1
| | | | | |
| | | | * | extract all channel and consumer related queue functionalityMatthias Radestock2013-12-232-383/+487
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | design decisions: - all limiter interactions take place in the new module. The alternative would turn into spaghetti and leave more code in amqqueue_process. - asynchronous channel interactions - namely delivery of messages and 'drained' events - happens in the new module whereas all other operations - really just sending of replies - takes place in amqqueue_process. I'm still in two minds about that. It would actually be simpler to have the rabbit_channel:deliver code in amqqueue_process, albeit in an existing closure, but send_drained is rather deeply embedded. - we need a few functions in the API that manipulate the channel record. They all require the same kind of post-processing to invoke decorators, run the message queue, etc. I decided to make this pattern explicit in the API by having just one function there - queue_consumers:possibly_unblock - that takes a closure. It has just one call site - amqqueue_process:possibly_unblock - that contains the post-processing logic. The closures are constructed by four separate API functions. There are a few complications... 1) event emission and decorator notifications These are deeply embedded in some places and need to be lifted out so they are all in the one logical place where they belong, namely amqqueue_process. In some cases this complicates the API and code a fair bit since we, e.g., need to collate information for subsequent decorator notification. This is doubly annoying since the existing decorators don't actually make use of that information, so we should really consider simplifying the decorator API. 2) message delivery logic This is a fairly complex piece of code and it gets more complicated still because a) of the above, and b) sending a message to a channel requires the queue name, so we need to pass that in. We also need the state, and indeed modify it, though this is done opaquely. And it looks like we could just pass BQ & BQS instead. 3) handle_cast/credit I reckon this should have been implemented with possibly_unblock. It is now. The behaviour isn't obviously equivalent, so this needs careful consideration. The old code would invoke 'unblock' when "(not Drain or Len /= 0) and updated channel record is not blocked". By contrast, the possibly_unblock logic, which is what the new code invokes, invokes 'unblock' when the old channel record is blocked and the updated channel record is unblocked. This would seem to be logical, and it would be weird indeed if the credit code relied on any different behaviour. 4) queue_consumer:add is a nine-arg function. urgh. Mind you, so is the handle_call/basic_consume message. There are some minimal refactors and cosmetic changes which should go straight onto 'default' and thus reduce the distance to changes in this bug.
| | | * | | merge stable into defaultMatthias Radestock2013-12-241-8/+6
| | | |\ \ \ | | |_|/ / / | |/| | | / | | | | |/ | | | |/|
| * | | | refactor: inlineMatthias Radestock2013-12-241-8/+6
| | | | |
| | | * | refactor: introduce helper to simplify update_consumer_use call sitesMatthias Radestock2013-12-241-15/+15
| | | | |
View Lorry Controller Status