delta/rabbitmq-server-git.git - github.com: rabbitmq/rabbitmq-server.git

	Commit message (Collapse)	Author	Age	Files	Lines
*	Drop unneeded queue impls, tidy lqueue, add specs etc	Matthew Sackman	2011-10-02	1	-273/+0
\|
*	Add 2,3-finger_tree implementation.	Matthew Sackman	2011-09-26	1	-1/+1
\|
*	bpqueue is very dependent on the performance of queue:join. fqueue makes ↵	Matthew Sackman	2011-09-23	1	-32/+34
\| \| \| \|	queue:join O(1) and maintains O(1) on other operations bpqueue cares about
*	Update .erl and .hrl license boilerplates	Matthew Sackman	2011-01-19	1	-26/+11
\|
*	Merging default into bug21673 and correcting specs and types	Matthew Sackman	2010-07-07	1	-0/+2
\|
*	cosmetic	Matthias Radestock	2010-05-14	1	-43/+28
\|
*	One more test, and simplification of the bpqueue:to_list function	Matthew Sackman	2010-05-13	1	-4/+1
\|
*	Improved documentation and added additional tests for bpqueue	Matthew Sackman	2010-05-13	1	-6/+12
\|
*	cosmetic	Matthias Radestock	2010-05-04	1	-10/+14
\|
*	cosmetic	Matthias Radestock	2010-05-04	1	-2/+4
\|
*	Fix the refactoring which broke bpqueue	Matthew Sackman	2010-04-12	1	-4/+4
\|
*	Apparently, abuse of empty queues is unsightly. Also, minor improvement to ↵	Matthew Sackman	2010-04-12	1	-4/+5
\| \| \| \|	documentation
*	refactor	Matthias Radestock	2010-04-12	1	-40/+33
\|
*	Merging default into bug21673 and correcting further copyright dates	Matthew Sackman	2010-02-10	1	-3/+3
\|
*	Refactoring of bpq	Matthew Sackman	2010-01-15	1	-129/+82
\|
*	Much better. The reason why batching is important is because if you're ↵	Matthew Sackman	2010-01-13	1	-37/+127
\| \| \| \|	walking through the bpqueue and doing very little work before stopping then you don't really get the amortised constant time behaviour. But the goal is achieved - throughput is maintained and very slowly diminishes with no major interruptions and the queue gets fuller and the transition is made to betas and then deltas.
*	Mechanism to limit the number of betas which don't have their index on disk ↵	Matthew Sackman	2010-01-13	1	-1/+69
\| \| \| \|	is now in. Testing showed that if the queue is long, the change in target_ram_msg_count can be large, thus driving the number of ram indices directly off that still doesn't solve the problem. Thus am driving it from publish, with a limit on the maximum amount of work that can be done. This should allow the queue to remain responsive, as it works towards its goal. However, further testing, tuning and thinking is still needed.
*	Refactoring of vq - pulled out the inlined block-prefix queue code and ↵	Matthew Sackman	2010-01-13	1	-0/+185
	generally tidied profusely. Also efficiency fix in remove_queue_entries by avoiding an intermediate list (which could potentially be massive).