Request for rabins to handle SIGHUP and reload the config?

[Carter Bullard]

I'm thinking that we should flush and start over regardless of the
configuration change.  Not very complicated, easy to describe predictable, etc....
Would that still do what you want ???

Carter

On Jan 28, 2014, at 8:54 AM, Matt Brown <matthewbrown at gmail.com> wrote:

> Carter,
> 
> Maybe this option (the "flush cache and use new bin size at N") can be passed at invocation?
> 
> That way, if someone has a bin of 24 hours, and a buffer of an hour, they can control how this new features works.
> 
> 
> What do you think?
> 
> 
> Thanks,
> 
> Matt
> 
> On Jan 27, 2014, at 2:47 PM, Carter Bullard <carter at qosient.com> wrote:
> 
>> Hey Matt,
>> So if you change the bin size and the hold time, if you can
>> wait for it to apply to the next time bin, then we don’t have
>> to do anything special.  But you may want the changes to apply
>> immediately, we’ll need to flush all the current bins and start
>> over.
>> 
>> Because there are a lot more options that can be changed,
>> we’ll have to consider how this new feature affects the strategy.
>> It would be easiest if we could just flush and start over again
>> regardless of the change, but there maybe an elegant way of
>> doing something more sophisticated……
>> 
>> But even with your limited example, if you’re running with 24
>> hour bins, and a “-B <secs>” option of 3600, and you
>> asynchronously change the bins size to, say 1s and a hold
>> time of 5s, then I doubt that you would be willing to
>> wait until tomorrow for the new bins to start ????
>> 
>> Once we figure out what we need to do, then should be no
>> problem.  It will have to wait until after we release 3.0.8
>> which should be in a few weeks, now that FloCon is over.
>> 
>> Carter
>> 
>> 
>> On Jan 27, 2014, at 2:08 PM, Matt Brown <matthewbrown at gmail.com> wrote:
>> 
>>> Thanks for replying, Carter.
>>> 
>>> My intention is to specifically change the bin size (by way of
>>> modifying a config file).
>>> 
>>> I would think it makes sense to:
>>> - allow caches to expire within a max timeout (N seconds.... maybe the
>>> -B ?  maybe the bin size? maybe either as a user wishes?)
>>> - rolling active flows won't be a problem, right?
>>> - Any config changes would take effect after the set expiration.
>>> 
>>> Do these make sense to you?
>>> 
>>> I think it makes the most sense to have a single rule ("everything
>>> takes effect after the previous [buffer|bin|whatever] ends"), than to
>>> make seperate rules ("if the bin size changes, then, we will flush
>>> cache after the latest bin expires." and/or "if the output filter
>>> changes, it will be immediate or maybe not.").
>>> 
>>> But... you know what makes the most sense from what you've seen from
>>> users over the years.
>>> 
>>> 
>>> Thanks much,
>>> 
>>> Matt
>>> 
>>> 
>>> 
>>> On Jan 23, 2014, at 8:01 PM, Carter Bullard <carter at qosient.com> wrote:
>>> 
>>>> Hey Matt,
>>>> Yes, but there is a lot of behaviors we need to define.
>>>> Do we flush all of the pending data and its caches when we change the configuration, or do we just keep plugging along, and let the caches time out ???  If we change bin sizes, well need to flush everything, if its output filters do they take immediate affect, or after the flush.  There are a lot of issues to consider.
>>>> 
>>>> What are you thinking about and what would you like for it to do ??
>>>> 
>>>> Carter
>>>> 
>>>>> On Jan 23, 2014, at 3:38 PM, Matt Brown <matthewbrown at gmail.com> wrote:
>>>>> 
>>>>> Hello all,
>>>>> 
>>>>> Carter:  is it possible to add SIGHUP handling to rabins() to reload
>>>>> the config file(s)?
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Matt
>>>>> 
>>> 
>> 
>> Carter Bullard
>> CEO/President
>> QoSient, LLC
>> 150 E 57th Street Suite 12D
>> New York, New York  10022
>> 
>> +1 212 588-9133 Phone
>> +1 212 588-9134 Fax
>> 
>> 
>> 
>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20140128/644d593e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6837 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20140128/644d593e/attachment.bin>