summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | |
* | | merge stable into defaultMatthias Radestock2013-12-2315-178/+326
|\ \ \ | |/ / |/| / | |/
| * stable to defaultSimon MacMullen2013-12-192-2/+5
| |\
| * \ stable to defaultSimon MacMullen2013-12-1915-178/+326
| |\ \
| | * \ Merged stable into defaultEmile Joubert2013-12-161-2/+10
| | |\ \
| | * \ \ Merge bug22525Simon MacMullen2013-12-124-6/+14
| | |\ \ \
| | | * | | Fix typeSimon MacMullen2013-12-121-1/+2
| | | | | |
| | | * | | SimplifySimon MacMullen2013-12-121-5/+3
| | | | | |
| | | * | | Merged stable into defaultEmile Joubert2013-12-112-0/+9
| | | |\ \ \
| | * | | | | maintain consistency of process dict channel entriesMatthias Radestock2013-12-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | (just as we used to)
| | * | | | | correct another returnMatthias Radestock2013-12-121-4/+3
| | | | | | |
| | * | | | | cosmeticMatthias Radestock2013-12-121-1/+1
| | | | | | |
| | * | | | | refactor: take advantage of channel_count to simplify maybe_closeMatthias Radestock2013-12-121-9/+6
| | | | | | |
| | * | | | | merge headsMatthias Radestock2013-12-120-0/+0
| | |\ \ \ \ \
| | | * | | | | channel_count is initialized in start_connectionMichael Klishin2013-12-121-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | which is invoked as soon as we get a valid handshake
| | * | | | | | refactor: take advantage of channel_count to simplify terminate_channelsMatthias Radestock2013-12-121-9/+7
| | | | | | | |
| | * | | | | | refactor: remove superfluous codeMatthias Radestock2013-12-121-1/+0
| | | | | | | |
| | * | | | | | refactor: two heads are better than oneMatthias Radestock2013-12-121-29/+28
| | | | | | | |
| | * | | | | | correct return valueMatthias Radestock2013-12-121-1/+1
| | | | | | | |
| | * | | | | | refactor: simplify and reduce distance to 'default'Matthias Radestock2013-12-121-11/+4
| | | | | | | |
| | * | | | | | refactor: simplify & consistencyMatthias Radestock2013-12-121-3/+4
| | | | | | | |
| | * | | | | | cosmetic: correct spacing, eliminate spurious diff to defaultMatthias Radestock2013-12-121-3/+3
| | | | | | | |
| | * | | | | | simplify (and stay below column limit)Matthias Radestock2013-12-121-3/+2
| | | | | | | |
| | * | | | | | correctly thread through the stateMatthias Radestock2013-12-121-2/+1
| | | | | | | |
| | * | | | | | correct handling of channel_cleanup return valueMatthias Radestock2013-12-121-11/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | plus some cosmetics in the area
| | * | | | | | refactor: simplify and reduce distance to 'default'Matthias Radestock2013-12-121-10/+9
| | | | | | | |
| | * | | | | | cosmetic: consistent field ordering (with start_connection code)Matthias Radestock2013-12-121-2/+2
| | |/ / / / /
| | * | | | | If channel pid is not in the process dict, don't decrement channel_countMichael Klishin2013-12-121-3/+3
| | | | | | |
| | * | | | | Decrement channel_count in channel_cleanupMichael Klishin2013-12-121-26/+28
| | | | | | |
| | * | | | | Nuke some unnecessary codeMichael Klishin2013-12-121-1/+0
| | | | | | |
| | * | | | | Init channel_count correctlyMichael Klishin2013-12-121-0/+1
| | | | | | |
| | * | | | | CompileMichael Klishin2013-12-121-2/+3
| | | | | | |
| | * | | | | Decrement channel counter here, tooMichael Klishin2013-12-121-1/+1
| | | | | | |
| | * | | | | Rename ChState back to AStateMichael Klishin2013-12-121-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | for assembler state.
| | * | | | | Decrement channel counter when handling channel.closeMichael Klishin2013-12-121-1/+1
| | | | | | |
| | * | | | | Move channel_count to top-level reader state recordMichael Klishin2013-12-121-9/+7
| | | | | | |
View Lorry Controller Status