summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* merge bug23152 into defaultMatthias Radestock2010-08-201-2/+3
|\
| * Grab the msg from the cur ets file cache, thus avoiding having to send the ↵Matthew Sackman2010-08-191-2/+3
| | | | | | | | same message many times
* | merge bug23139 into defaultMatthias Radestock2010-08-201-146/+196
|\ \ | |/ |/|
| * oopsMatthias Radestock2010-08-201-4/+4
| |
| * merge headsMatthias Radestock2010-08-201-15/+13
| |\
| | * simplification due to the fact that we always request closing of allMatthias Radestock2010-08-201-7/+5
| | |
| | * cosmeticMatthias Radestock2010-08-201-8/+8
| | |
| * | ensure_mref => track_client andalso cosmeticMatthew Sackman2010-08-201-11/+11
| |/
| * Merging headsMatthew Sackman2010-08-200-0/+0
| |\
| | * cosmetic and some minor refactoringMatthias Radestock2010-08-201-30/+30
| | |
| | * fix bug that crept inMatthias Radestock2010-08-201-3/+4
| | |
| * | Convert fhc to use an ets table with record per client which amalgamates ↵Matthew Sackman2010-08-201-145/+135
| |/ | | | | | | several of the previous state entries
| * Given the clients are demanded to close all open fds when asked to, them ↵Matthew Sackman2010-08-201-10/+9
| | | | | | | | sending a boolean is irrelvant now
| * If we sent an age of 0 to clients, make sure we do not send more ages of 0 ↵Matthew Sackman2010-08-201-39/+58
| | | | | | | | | | | | to the same clients until they've actually closed all their handles. This ensures that as more requests come in once we're low on fds, we don't send hundreds of 0 ages to the same clients erroneously. It also means that we always target the correct number of *unique* clients to ask to close their fds, which avoids thrashing the same clients and improves performance markedly. Also, if on open, we send "close" back to the client, that client *is* blocked (actually, due to have 0 opens) as we know it'll close, send us some closed msgs and then re do the open call. Thus we shouldn't be sending it any set maximum age messages.
| * refactorMatthias Radestock2010-08-191-16/+23
| |
| * cosmeticMatthias Radestock2010-08-191-11/+11
| |
| * Some essential assertionsMatthew Sackman2010-08-191-5/+5
| |
| * More meaningful variable nameMatthew Sackman2010-08-191-2/+2
| |
| * WhoopsMatthew Sackman2010-08-191-1/+1
| |
| * Reworked substantiallyMatthew Sackman2010-08-191-88/+117
| |
| * Merging default into bug 23139 (substantial debitrot)Matthew Sackman2010-08-1910-144/+126
| |\
| * | The solution is very simple: In the case where the fhc sends out requests to ↵Matthew Sackman2010-08-171-1/+3
| | | | | | | | | | | | close file handles, the clients might respond very quickly. The fhc will then gather these responses (say, just updates, not closes) and then will sit there for 2 seconds until the timer goes off. Thus the solution is just to subtract the timer period from the calculated average: i.e. the expression is to say 'close file handles that haven't been used for N seconds from NOW' rather than the previous 'close file handles that haven't been used for N seconds from NOW - 2 seconds ago'. This works very nicely and whilst the fhc can get quite busy when there are more users of file handles than there are file handles available, that is hardly surprising, and the fact is starvation is prevented and processes are promptly serviced
| * | Track blocked pids explicitlyMatthew Sackman2010-08-171-27/+42
| | |
* | | merge bug23150 into defaultAlexandru Scvortov2010-08-191-1/+1
|\ \ \ | |_|/ |/| |
| * | Use string tokens, not re:splitMatthew Sackman2010-08-191-1/+1
|/ /
* | Merging bug 23138 into defaultMatthew Sackman2010-08-192-86/+126
|\ \
| * | once again allow use of fhc w/o registeringMatthias Radestock2010-08-191-4/+7
| | |
| * | refactorMatthias Radestock2010-08-191-3/+5
| | |
| * | rewriteMatthias Radestock2010-08-192-103/+94
| |/
| * Correct monitoring and actions upon DOWN messages. Note this is especially ↵Matthew Sackman2010-08-171-65/+105
| | | | | | | | subtle for obtains, which effectively implicitly allocates temporarily to the blocked caller (FromPid) whilst monitoring it, and then transfers this to the ForPid when possible. Note the ForPid can die before the obtains is processed, which which point the FromPid must be replied to immediately.
* | Don't ever keep the recovery process waiting, regardless of whether the ↵Matthew Sackman2010-08-181-1/+2
| | | | | | | | | | | | queue is going down or not (transplanted from 4c99ba7eedd4b28a096d0412bbbdacb1fa91daa3)
* | A rather crucial infinity missingMatthew Sackman2010-08-181-1/+2
| | | | | | | | (transplanted from aaf79aa3cacefee1742eb7f257c6a16ec5720d59)
* | re-merge rebased bug23145 into new head of defaultMatthias Radestock2010-08-184-23/+13
|\ \
| * | Eliminate RABBITMQ_PLUGINS_EXPAND_DIRDavid Wragg2010-08-184-23/+13
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were a number of issues with RABBITMQ_PLUGINS_EXPAND_DIR: - It was undocumented in the context of the generic unix package, and if unwisely set could do an effective "rm -rf" in an unintended location. - It did not take account of the possibility that multiple nodes could be starting at once, and so doing plugins activation simultanteously. Instead, use RABBITMQ_MNESIA_DIR/plugins-scratch. This avoids the need to extend the generic unix package documentation, the location is node-specific, and the distinctive plugins-scratch subdirectory reduces the risk of unintended file deletions. (transplanted from 064b8797493bb290156fb72a54f9e9276df0faed)
* | small simplifying refactorMatthias Radestock2010-08-181-15/+13
| |
* | take current memory alarms status into account straight awayMatthias Radestock2010-08-181-3/+4
|/ | | | | | | | | | | | | | | | | | | | | | | | | This does in fact not alter the behaviour at all due to the following: - if the alarm is active the alarm registration will call the handler straight way, which will send a {conserve_memory, true} message to the reader. - the reply to the alarm registration is sent after that, and from the same process - the alarm process - so by the time the reader loops around the mainloop again the {conserve_memory, true} message is guaranteed to be in the mailbox - on looping around, the reader request a frame_header from the socket. The reader has already sent connection.open_ok to the client, and the client may have started sending commands straight away. But all the reader is going to see of that to start with is an {inet_async, ...} message for a frame_header. That is guaranteed to end up in the mailbox after the {conserve_memory, true} message. Thus the reader is guaranteed to process the {conserve_memory, true} message before handling any more data from the socket. With this change it is rather more obvious that the memory alarm status gets taken into account before any more client data is processed.
* merge bug23135 into defaultMatthias Radestock2010-08-172-22/+23
|\
| * obtain_and_release_on_death => obtain, and minor refactor of tcp acceptorMatthew Sackman2010-08-172-16/+14
| |
| * Combine obtains and release_on_deathMatthew Sackman2010-08-172-30/+33
|/
* merge bug23132 into defaultMatthias Radestock2010-08-171-76/+165
|\
| * Minor correctionsMatthew Sackman2010-08-171-4/+5
| |
| * cosmeticMatthias Radestock2010-08-161-1/+1
| |
| * tweakMatthias Radestock2010-08-161-2/+2
| |
| * tweakMatthias Radestock2010-08-161-5/+5
| |
| * tweakMatthias Radestock2010-08-161-1/+1
| |
| * obtain_limit can be 'infinity'Matthias Radestock2010-08-161-1/+1
| |
| * cosmeticMatthias Radestock2010-08-161-1/+1
| |
| * refactor: incorporate limit checking into maybe_reduceMatthias Radestock2010-08-161-26/+22
| |
| * cosmeticMatthias Radestock2010-08-161-26/+35
| |
| * opens => open. obtains => obtainMatthew Sackman2010-08-161-61/+61
| |
View Lorry Controller Status