Event-Timestamp

[Alan DeKok]

Arran Cudbard-Bell wrote:
> Ok and it's expanded to the string form with the double quotation marks?
> why ?

  Bug.  Some things have extra quotation marks.  This is fix in 2.0.3,
or maybe CVS.

> Indeed, I did something in unlang, but it'd be nice to have it in the
> server core. Then I can update the SQL queries with
> %{%{Packet-Original-Timestamp}:-%S} and it should all just work.

  Done.

> Another thing I noticed recently: For file based buffers the server
> takes the detail file moves it to detail.work, processes all entries in
> the work file then repeats the process.

  Yes.  It has to do that for a number of reasons.

> On one of our servers I made a typo when recreating the symbolic link to
> start the detail reading server, I didn't notice the error for a number
> of days, by which time the detail file was ~400mb. Our servers are
> restarted nightly and the rate of inserts is so slow that the server
> can't get through 400mb of detail file in under 24hrs. So when it's
> restarted the whole process starts again.
> 
> It's not a huge problem, as accounting data isn't massively important to
> us, but possibly putting an upper limit on the .work file might be useful.

  It can't, because it's just a renamed "detail" file.  If the detail
file is 400M, so is detail.work.

  The larger issue is that it's hard to keep track of which parts of the
"detail.work" file have been read && responded to.  I've had a few
ideas, but nothing that really makes sense.

  I'll play with some things to see if I can get that last piece fixed.
 if you're OK with the "detail.work" file being written to, there may be
a solution.

  Or, update it so that it reads *all* of the detail files in a
directory.  That way, the process writing the detail files can write
them every hour, day, etc.

  Alan DeKok.