Skip to Content.
Sympa Menu

perfsonar-user - TTL for LS records

Subject: perfSONAR User Q&A and Other Discussion

List archive

TTL for LS records


Chronological Thread 
  • From: "Vedrin Jeliazkov" <>
  • To:
  • Cc:
  • Subject: TTL for LS records
  • Date: Wed, 23 Aug 2006 19:00:56 +0300

Hi All,

After having played with the recent versions of LS, I started to wonder if the
concept of time-to-live (TTL) is implemented in the LS. I mean - what should
happen if a given service registers with LS and unexpectedly fails later on.
Should the LS remove the respective entry from its database after some TTL has
elapsed after the last successful service registration? I expected to see such
behaviour, but this doesn't happen in ISTF's LS (the record stays forever,
unless an explicit de-register request is sent). We're running the latest
snapshot (perfSONAR-LS-src-snapshot-20060720.tar.gz). I'm not sure if it is
supposed to be that way or we have some problem with our specific LS
installation/configuration.

Another related question is - what's the purpose of the
"component.ls_cleanup_loader.interval" - initially I presumed that this is in
fact the above mentioned TTL, but I'm not so sure anymore...

The answers to the above questions are important for the development of
perfsonarUI's interactions with LS. We have to know if the client could rely
on the "freshness" of the records in LS or should check the registration
timestamps and apply a TTL mechanism itself.

Thanks for your comments and sorry for my laziness (I haven't thoroughly
checked if this info is available in some document).

Kind regards,
Vedrin

PS: The current contents of our LSStore-control.xml is as follows:

<!-- Purpose: Holds the control information for registered services
-->
<nmwg:store xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/";
xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
xmlns:psservice="http://ggf.org/ns/nmwg/tools/org/perfsonar/service/1.0/";
xmlns:perfsonar="http://ggf.org/ns/nmwg/tools/org/perfsonar/1.0/";
xmlns:netutil="http://ggf.org/ns/nmwg/characteristic/utilization/2.0/";
type="LSStore-control">
<nmwg:metadata
id="http://selena.acad.bg:8080/axis/services/MeasurementArchiveService";>
<nmwg:parameters id="control-parameters">
<nmwg:parameter name="timestamp">1156345621965</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>
<nmwg:metadata id="http://gandalf.rrze.uni-erlangen.de:3456";>
<nmwg:parameters id="control-parameters">
<nmwg:parameter name="timestamp">1155298972966</nmwg:parameter>
</nmwg:parameters>
</nmwg:metadata>
</nmwg:store>

The second timestamp equals Friday, August 11th 2006, 12:22:52 (GMT), we have
a component.ls_cleanup_loader.interval set to six hours, and today is August
23rd...
--
-----------------------------------------------------------------
* * Vedrin JELIAZKOV - Network Engineer
* * Institute for Parallel Processing
* IST Foundation * Bulgarian Academy of Sciences
* The Bulgarian NREN * Acad. G. Bonchev St 25-A
* * 1113 Sofia, Bulgaria
* * Tel: +3592 9796606
http://www.ist.bg ICQ: 42633308
-----------------------------------------------------------------
PGP Public Key
http://cert.acad.bg/pgp-keys/keys/vedrin-jeliazkov-0x0F7EF249.asc
7EA1 7539 9B83 D8BF 4C1D 4890 0CE5 0B4B 0F7E F249
-----------------------------------------------------------------





Archive powered by MHonArc 2.6.16.

Top of Page