In summary, I don't dispute anything we've so far discussed.
I would however posit that we should not lose sight of the impact(s) of any solution on the various affected elements (store space, recovery/backup times, index rebuilding requirements ? etc). This is the key point I'm making - along with testing our various assumptions about performance :-) We need to able to explain/forecast the likely impact on an application of introducing reply - so we can explain it to our users. The only other point I'd make is my opening one - we need to be careful where we want to draw the line between message replay and running reports etc against retained messages. Sure we might want to support message selectors etc, but there has to be a line and SQL style features is surely it. As many users will be currently using an RDBMS for replay style functionality we should be careful not to go down the path of adding features to take their RDBMS reqs out of the picture. This would almost certainly be a mistake ! Marnie On 1/25/07, John O'Hara <[EMAIL PROTECTED]> wrote:
That's fine. A design assumption should be to hold 5 days messages in the store. This is more of a space than a performance issue. People who need this can pay for the disk. That means that a queue size could be 500% of a day's activity. If I were to use Qpid in serious business application, that could be 1 million 16KB messages. About 100GB in total. Looking forward, I'd imagine that the way disk and compute are going the architecture will need to cater for large storage sizes. Hitachi will release a 1TB PC hard disk this quarter, and it won't cost a fortune. John On 25/01/07, Marnie McCormack <[EMAIL PROTECTED]> wrote: > > Hi, > > Re below - surely one key point in this discussion around replay thus far > has included the idea that delivered messages stay in the store. Thus, the > store (and queues) could potentially get far larger than otherwise ..... > > Marnie > > > On 1/25/07, Robert Greig <[EMAIL PROTECTED]> wrote: > > > > I think (hope!) the backup and restore times will be proportional to > > the number of messages in the store, irrespective of whether they are > > delivered or pending delivery. > > > > RG > > > >
