hi David,
yes, variable substitution can be added to Calendar rule, but I was
thinking of other actions which might still benefit from certain timestamp
parts (like using 'write' action for producing files with day-month-year).
The number of different timestamp formats is of course endless, but maybe
parsing out some basic elements (like perl localtime() does) would allow to
simplify some 'lcall' actions with @array = localtime(). I had a look into
the function which substitutes action list variables, and because of %t and
%u it invokes time() anyway. This function can be optimized, though, by
setting up extra action list variables only once when clock moves into the
next second, caching them for the rest of the second.
One caveat with action list variables is the substitution -- if these
variables would have the format %_name, that might overlap with some perl
hash names in 'eval' actions. Due to substitution, perl hashes have to be
masked with an extra % (like %%myhash) in 'eval' code, but there might be
some code snippets around which are not following that convention for
underscore prefixed hashes (since so far this shortcut has worked). So
maybe it would be safer to select another prefix than underscore which
can't be used in perl hash name (like %{.day} or %{!month}). Anyway, that
idea would need a bit more thinking and testing, in order to verify it's
actually the best way.
Any thoughts?
kind regards,
risto
2016-02-10 20:39 GMT+02:00 David Lang <[email protected]>:
> Since there are not any match variables in a calendar rule, I was thinking
> that using them would ensure no conflicts.
>
> normally you don't care when the action is being taken, and so it's a
> waste of time to do the lookup and set the variables.
>
> but in the calendar case, you have to lookup the info anyway (to decide if
> the rule matches), so setting it in a way that can be retrieved should be
> cheap/free.
>
> David Lang
>
>
> On Wed, 10 Feb 2016, Risto Vaarandi wrote:
>
> when thinking quickly about it, it might be a better idea to provide time
>> related data through action list variables. Currently there are already
>> variables %t and %u which refer to current time in textual and numerical
>> format, so action list variable approach would fit with an already
>> existing
>> scheme. Also, such approach would allow to access new variables not only
>> from Calendar but all rules. The only downside of this is that these
>> additional variables are set for every action invocation, but since
>> actions
>> are generally not triggered by thousands per each second, performance
>> penalty might be minimal.
>>
>> The only question which remains open is the following -- since currently
>> action list variables must start with a letter and can contain letters,
>> numbers and underscores, introducing new reserved variables might clash
>> with existing variables. One option to prevent this might be the use of _
>> prefix for reserved action list variables (like %{_month} or %{_day}).
>>
>> kind regards,
>> risto
>>
>> 2016-02-10 11:11 GMT+02:00 David Lang <[email protected]>:
>>
>> I have a case where I am using calendar events to summarize logs, with
>>> each
>>> summary ending up in it's own file due to the way I'm rotating the files.
>>> Each
>>> rotated file has the timestamp info in the filename.
>>>
>>> I want to change this to rotate less frequently, but to do this, I need
>>> to
>>> add
>>> the timestamp to each line in the file. I could import time and look it
>>> up
>>> as
>>> needed, but then I would run the risk of processing taking too long and
>>> the
>>> timestamp changing on me (and so not matching when the dump started)
>>>
>>> It occures to me that if we could have the values of time (which get
>>> matched
>>> with the time= line) put into the $1-$5 variables, it would make this
>>> more
>>> reliable, and shouldn't hurt any existing configs, because they can't be
>>> using
>>> $<number>
>>>
>>> does this sound like a reasonable thing to do? and does it sound like an
>>> easy
>>> thing to do?
>>>
>>> David Lang
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor end-to-end web transactions and take corrective actions now
>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>> _______________________________________________
>>> Simple-evcorr-users mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>>>
>>>
>>
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
