Bug #2438

StatusDataset does not change

Added by Alex Afanasyev over 6 years ago. Updated over 6 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
2.00 h


I cannot yet track down on the exact cause of the problem, but the highlights. This could be a combination of pre-existing issue with SegmentPublisher and new CS implementation



... wait some time



Face list changes from time to time (at least it should show nfd-status own face)


Face list and other things (except ServerStatus) stay the same


Updated by Alex Afanasyev over 6 years ago

From what I observing, SegmentPublisher doesn't set FreshnessPeriod.

I think in previous CS implementation this was treated as "stale" packet. Right now it is most likely treated as never stale packet. This effectively prevents getting any new data packet using status dataset protocol / segment fetcher.


Updated by Alex Afanasyev over 6 years ago

  • Tracker changed from Task to Bug

Updated by Alex Afanasyev over 6 years ago

  • Category changed from Core to Tables

I just confirmed that setting FreshenssPeriod=1ms on data packets published by the SegmentPublisher fixes the problem.

I declare that this is the issue with the new content store.


Updated by Junxiao Shi over 6 years ago

  • Subject changed from Status datasets (based on SegmentPublisher) are effectively broken to StatusDatasets does not change
  • Category changed from Tables to Core
  • Assignee deleted (Junxiao Shi)
  • Priority changed from Immediate to Urgent

ContentStore is correct.


When FreshnessPeriod is omitted, the Data packet cannot be marked stale.

A Data packet without FreshnessPeriod field is never stale. Its effective FreshnessPeriod is infinite.

SegmentPublisher needs to set FreshnessPeriod.
The FreshnessPeriod shall be an argument, whose default is 5 seconds.


Updated by Junxiao Shi over 6 years ago

  • Subject changed from StatusDatasets does not change to StatusDataset does not change
  • Assignee set to Anonymous
  • Estimated time set to 2.00 h

I'm assigning this to @Steve because he is the original author of SegmentPublisher in commit:9f6c3642ceb8bb29e38549ae916019ac89612569

The challenge here is how to make a test case.


Updated by Anonymous over 6 years ago

  • Status changed from New to In Progress

I think the test case should just check that FreshnessPeriod has been set to the specified value.


Updated by Anonymous over 6 years ago

  • Status changed from In Progress to Code review
  • % Done changed from 0 to 70

This problem is clearly my fault (pretty sure I violated the original task spec), but it got me thinking about the ndn-cxx Data constructors. What's the motivation for unlimited lifetime being the default behavior?

It seems that application developers should be carefully considering the freshness period of their data (just like they do with name structure). Would it be better to make freshness a constructor argument? Possibly with some short (e.g. 1ms) default value?


Updated by Alex Afanasyev over 6 years ago

2Steve. we can discuss that during the call today.

In general, I'm very curisois why exactly it was working before. Was my guess anout different behavior in CS correct or there are other pieces involved?


Updated by Anonymous over 6 years ago

Is this the root of the behavior? (as of commit 27533da4f13e20dc8f7b0f5cf531d3b65b2e94e4)

  m_staleAt = time::steady_clock::now() + m_dataPacket->getFreshnessPeriod();

I'm guessing getFreshnessPeriod() returns -1, so the packet was already stale. The new CS entry checks that getFreshnessPeriod() is positive in updateStaleTime(), else maxes out the stale time.


Updated by Junxiao Shi over 6 years ago

  • Status changed from Code review to Closed
  • % Done changed from 70 to 100

Verified on NDN6.TK node

Also available in: Atom PDF