http://qs321.pair.com?node_id=562161


in reply to Re^2: Saving and Loading of Variables
in thread Saving and Loading of Variables

me elides a long post which was made totally wrong by your clarification of the data

The updated data is much more helpful, but still leaves some significant questions. For instance, the order in the hash keys of your combined tests does not seem to be related to the order in which they appear in the log file (compare "BAYES_99+URIBL_SBL" v. "URIBL_SBL+SPF_HELO_SOFTFAIL"). The "Totals" seem to imply that they are gathered over multiple runs, while "Value" is obviously the sum of the conditions matched by the current message only. And to be fair, this is the first time you mentioned wanting to record the combined score. I think your requirements need better definition: exactly what are you trying to measure?

There is no way to guarantee that all of your processed data will be saved (think power failure). You need to decide what an acceptable level of data loss is. You will need to write out the current state to a checkpoint file (whether through a database, Storable, Data::Dumper or whatever) at least once before you exit. The more often you checkpoint, the less data you risk losing. The truly paranoid will note that you need some sort of transactional locking to protect against interruption in mid-update.

You could install a signal handler to catch most of the things that could kill your program and have it checkpoint your current status. It won't work for non-maskable signals (or power cuts), but might help with your stated aversion.

For the task you describe, you might want to consider just rotating your logs nightly (or hourly, depending upon your volume) and processing them "offline" rather than tailing the live log file. It avoids most of these concerns.


The intelligent reader will judge for himself. Without examining the facts fully and fairly, there is no way of knowing whether vox populi is really vox dei, or merely vox asinorum. — Cyrus H. Gordon