qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Straw Poll: proposal to remove certain features from qpidd
Date Tue, 07 Aug 2012 18:11:52 GMT
So, to follow up and summarise this thread so far, the only contentious 
point has been the loss of the 'flow to disk' functionality.

Though the current solution doesn't limit the memory used by a large 
queue, it can in certain cases reduce the rate of memory growth which in 
turn may buy a little more time to resolve the root cause. So while 
those using it are less than fully satisfied, they are (understandably) 
concerned at having even this limited solution taken away without having 
any clear plan to offer a replacement.

I have spent a little time thinking through what a better solution might 
look like and how much effort it would take. I believe that for ~3-5 
weeks work I could get something better in place. It would be, in the 
first instance, posix only[1]. It would be mutually exclusive with lvq 
or priority queue options. However it would be a more effective limit on 
the memory consumed as such a queue grew, and (I hope) would have a less 
drastic performance penalty at larger sizes.

There are a few options for how to proceed, and I'd like to take a quick 
straw poll to see which path the community favours.

(a) go ahead with the refactor, including the removal of features 
mentioned in the previous mail, subsequently focus first on AMQP 1.0 
support, only then return to add paged queue support

(b) go ahead with the refactor, including the removal of features 
mentioned in the previous mail, subsequently focus first on paged queue 
support, then proceed to add AMQP 1.0 support

(c) don't go ahead with the refactor until it can be combined with an 
alternative to flow to disk, and only then proceed with AMQP 1.0 support

(d) don't go ahead with the refactor at all

I myself favour (a). I think AMQP 1.0 support is more important and more 
work and would like to make more progress on that as soon as possible in 
order to have something ready for the 0.20 release. I can't guarantee 
that this path would result in the 0.20 release having the replacement 
for flow to disk functionality, but if not it would come soon after.

I'm not so keen on (c) because maintain such a large patch against a 
continually moving trunk is a lot of work in itself and I think that 
time can be better spent. I'm not keen on (d) because I honestly don't 
think I can add decent 1.0 support (or fix a number of known issues) 
without something like this refactor.

Anyway, over to you. Let me know what you think, I'm keen we reach some 
agreement by the end of the week. In the meantime I'll try and make my 
proposal for the flow to disk replacement a bit more concrete.

--Gordon.

[1] It will be designed such that it is relatively simple to provide 
alternative implementations for the posix functionality such that anyone 
with interest can easily add windows support for example. From what I 
can tell, it doesn't look like flow to disk is supported on windows at 
present anyway. I could be wrong.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message