[rrd-users] does rrdcached grok millisecond timestamps?

Rick Jones rick.jones2 at hp.com
Wed May 11 22:30:05 CEST 2011


I'm working on getting my little utility communicating with an rrdcached
and so I've added code to add the --daemon <path> to the argv passed in
an rrd_update() call.  However, when I start my utility with it pointed
at the rrdcached, I get error messages such as:

2011-05-11T13:04:39.353966-07:00 s132 ./sfstored[6363]:
update_generic_counter_db() rrd_update() returned 'rrdcached: Cannot
find timestamp in
'1305144276.651:83:117:10000000000:1:3:482259330:2787704:1464022:124284676:0:0:0:645919723:1699360:437635:86:0:0:2'!'

which I do not get when I do not attempt to use the rrdcached.  Looking
at:

http://www.mail-archive.com/rrd-developers@lists.oetiker.ch/msg02670.html

I see where that error message was added, and it appears the code is the
same in 1.4.5:

    /* make sure update time is always moving forward */
    stamp = strtol(value, &eostamp, 10);
    if (eostamp == value || eostamp == NULL || *eostamp != ':')
    {
      pthread_mutex_unlock(&cache_lock);
      return send_response(sock, RESP_ERR,
                           "Cannot find timestamp in '%s'!\n", value);
    }
    else if (stamp <= ci->last_update_stamp)

The use of strtol() suggests that the rrdcached (at least up through and
including 1.4.5) does not grok millisecond timestamps?  My guess is that
the calls are hitting the '*eostamp != ":"' check and failing since it
will be "." after the strtol() call.

That seems to be further born-out by the definition of a cache_item:

struct cache_item_s;
typedef struct cache_item_s cache_item_t;
struct cache_item_s
{
  char *file;
  char **values;
  size_t values_num;
  time_t last_flush_time;
  time_t last_update_stamp;
#define CI_FLAGS_IN_TREE  (1<<0)
#define CI_FLAGS_IN_QUEUE (1<<1)
  int flags;
  pthread_cond_t  flushed;
  cache_item_t *prev;
  cache_item_t *next;
};

where last_update_stamp is simply a time_t.  Am I correct in calling
this a bug?

happy benchmarking,

rick jones



More information about the rrd-users mailing list