• New Feature
  • Status: Open
  • 2 Major
  • Resolution:
  • Statistics
  • prodmgmt
  • Reporter: gbevin
  • April 07, 2008
  • 0
  • Watchers: 0
  • March 19, 2010


Different buffer implementations can be useful wrt. preventing intervention with the actually captured statistics data and actual system requirements.

For instance, a memory buffer implementation would lack several features: being able to retrieve statistics on a client that crashed but that hasn’t sent out the buffered data yet or when there’s a network bottleneck; storing all the data locally until the end of the capture session so that nothing would intervene in the network usage. However, it would reduce the impact on disc statistics and not require correct configuration of the embedded buffer database location.

To evaluate buffer implementation alternatives, I think we should work from real life use cases that can now be done since the system is available to everyone … then we can work from there.


Geert Bevin 2008-04-15

I just thought of a very unintrusive ‘fix’ that would allow both in-memory and on-disk statistics buffering to be possible with the current implementation. H2 can be run in memory-only mode where nothing is written to disc, this is merely a change to the JDBC connection URL. I’d also have to remove the additional file locking that I added around the entire database installation, but besides that it should be no effort.