Aled, Martin, All-
I've been commenting on the PR [1]. This information can be very useful
in the event that there is latency during the persistence so I've
suggested a conditional debug/trace.
Best
Alex
[1] https://github.com/apache/incubator-brooklyn/pull/686
On 11/06/2015 14:17, Aled Sage wrote:
+1
If we want to get fancy, we could keep a count and log that every 100
writes or some such (but not convinced it's worth that).
---
Longer term, a better design would be for the persister code (that you
referenced) to keep counts for add/update/delete, time spent
persisting, etc.
A logger thread can then query for the stats, and include that in a
periodic report.
Currently, there is a message written once per minute by
`BrooklynGarbageCollector.gcIteration`, which includes some metrics.
We could generalise that further, perhaps.
Aled
On 11/06/2015 08:13, Martin Harris wrote:
For clarity, I'm suggesting we change the code to use LOG.trace(xxx)
instead of LOG.debug(xxx) here[1] <http://git.io/vIMXc> and here[2]
<http://git.io/vIMXj>
[1]: http://git.io/vIMXc
[2]: http://git.io/vIMXj
Cheers
M
On 11 June 2015 at 10:45, Martin Harris
<[email protected]>
wrote:
Hi Folks,
Any consensus on switching the log level
for ManagementPlaneSyncRecordPersisterToObjectStore
and PeriodicDeltaChangeListener from DEBUG to TRACE? The checkpointing
messages from these classes account for around a full third of all log
messages, which seems a bit excessive. It's fine if you're greping, or
searching for something specific, but a `tail -f` is just swamped with
checkpoint messages
Cheers
--
Martin Harris
Lead Software Engineer
Cloudsoft Corporation Ltd
www.cloudsoftcorp.com
Mobile: +44 (0)7989 047-855
--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
