[Xastir-dev] Mysteriously non-vanishing deleted stations?

[Tom Russo]

On Wed, Mar 07, 2007 at 07:29:58AM -0800, we recorded a bogon-computron collision of the <archer at eskimo.com> flavor, containing:
> On Tue, 6 Mar 2007, Tom Russo wrote:
> 
> > Looking at the code quickly, it looks like xastir's supposed to be completely
> > deleting station records after the station delete time, not just marking
> > them inactive in some way.  Is that right?
> 
> There's a ghosting time and then a clearing/deleting time.  Stations
> are supposed to have one of three states:
> 
>   Active
>   Ghosted
>   Time to be deleted
> 
> It looks like we have yet another counter in there as we have a
> sec_clear and a sec_remove.  

Yeah, that was what I saw.  From the usage of sec_remove it appears that the
code is supposed to purge the record from the DB when it's that old.  That
appears not to be happening.

> > Does anyone else have a long-running instance of xastir (24 days or older)
> > that can check to see if their "Include Expired Data" shows stations that
> > vastly exceed the age supposedly allowed by the station delete time?
> 
> I have one instance at home in the 2+ days category and one station
> at work currently at 63+ days.  I'll take a look.  I seem to have
> noticed more memory usage over the last month or three.  Perhaps
> station expiration has something to do with it.

I'm curious what you see.  My settings are:
DEFAULT_STATION_OLD:10800
DEFAULT_STATION_CLEAR:64800
DEFAULT_STATION_REMOVE:86400

which is 3 hours, 18 hours, and 1 day, and I am seeing that "Include Expired
Data" resurrects stations that are over 10 days old.  I'm thinking the deletes
aren't happening.

> 
> > If this is something that was addressed in a recent commit (I dimly recall
> > some commit messages about clearing out data, but can't remember what they
> > were), then I'll just update, but if not, then a debugging run is in order.
> 
> As I recall it had to do with weather alert expirations.  I don't
> think anyone has touched station expiration code in a while.
> Perhaps a tweak here or there to get rid of compiler warnings
> screwed something up.

That sounds right.  Well, looks like debugging time.

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick