[
https://issues.apache.org/jira/browse/CASSANDRA-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14500127#comment-14500127
]
Andy Tolbert commented on CASSANDRA-9131:
-----------------------------------------
{quote}
if we should update the client protocol spec/docs to make clear that this
problem exists, and that clients are expected to work around it
if we should offer some sample code, and work with the Java Driver team to
ensure this problem doesn't affect it
{quote}
This is something I'm actively looking at on the drivers side for each driver.
As of now only the python-driver and java-driver have a mechanism to enable
automatically set client timestamps. The other drivers that support 2.1 have a
mechanism of the client specifying the timestamp (they could also use 'USING
TIMESTAMP' i suppose), so it will be up to user / time implementation. Most of
the drivers will have an active means of setting client timestamp through API
by June 30th 2015.
* python-driver: [Session
use_client_timestamp|http://datastax.github.io/python-driver/api/cassandra/cluster.html?highlight=timestamp#cassandra.cluster.Session.use_client_timestamp]
not monotonic, uses time.time().
* java-driver:
[TimestampGenerator|http://www.datastax.com/drivers/java/2.1/com/datastax/driver/core/TimestampGenerator.html].
All client implementations are monotonic, but client can provide their own.
If > 999 entries for same millisecond, will reloop over the same millisecond,
so its not completely monotonic. Possible problem if > 1000 entries during
leap second
([code|https://github.com/datastax/java-driver/blob/2.1/driver-core/src/main/java/com/datastax/driver/core/AbstractTimestampGenerator.java])
> Defining correct behavior during leap second insertion
> ------------------------------------------------------
>
> Key: CASSANDRA-9131
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9131
> Project: Cassandra
> Issue Type: Bug
> Environment: Linux ip-172-31-0-5 3.2.0-57-virtual #87-Ubuntu SMP Tue
> Nov 12 21:53:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Jim Witschey
> Assignee: Jim Witschey
>
> On Linux platforms, the insertion of a leap second breaks the monotonicity of
> timestamps. This can make values appear to have been inserted into Cassandra
> in a different order than they were. I want to know what behavior is expected
> and desirable for inserts over this discontinuity.
> From a timestamp perspective, an inserted leap second looks like a repeat of
> the previous second:
> {code}
> $ while true ; do echo "`date +%s%N` `date -u`" ; sleep .5 ; done
> 1435708798171327029 Tue Jun 30 23:59:58 UTC 2015
> 1435708798679392477 Tue Jun 30 23:59:58 UTC 2015
> 1435708799187550335 Tue Jun 30 23:59:59 UTC 2015
> 1435708799695670453 Tue Jun 30 23:59:59 UTC 2015
> 1435708799203902068 Tue Jun 30 23:59:59 UTC 2015
> 1435708799712168566 Tue Jun 30 23:59:59 UTC 2015
> 1435708800220473932 Wed Jul 1 00:00:00 UTC 2015
> 1435708800728908190 Wed Jul 1 00:00:00 UTC 2015
> 1435708801237611983 Wed Jul 1 00:00:01 UTC 2015
> 1435708801746251996 Wed Jul 1 00:00:01 UTC 2015
> {code}
> Note that 23:59:59 repeats itself, and that the timestamps increase during
> the first time through, then step back down to the beginning of the second
> and increase again.
> As a result, the timestamps on values inserted during these seconds will be
> out of order. I set up a 4-node cluster running under Ubuntu 12.04.3 and
> synced them to shortly before the leap second would be inserted. During the
> insertion of the leap second, I ran a test with logic something like:
> {code}
> simple_insert = session.prepare(
> 'INSERT INTO test (foo, bar) VALUES (?, ?);')
> for i in itertools.count():
> # stop after midnight
> now = datetime.utcnow()
> last_midnight = now.replace(hour=0, minute=0,
> second=0, microsecond=0)
> seconds_since_midnight = (now - last_midnight).total_seconds()
> if 5 <= seconds_since_midnight <= 15:
> break
> session.execute(simple_insert, [i, i])
> result = session.execute("SELECT bar, WRITETIME(bar) FROM test;")
> {code}
> EDIT: This behavior occurs with server-generated timestamps; in this
> particular test, I set {{use_client_timestamp}} to {{False}}.
> Under normal circumstances, the values and writetimes would increase
> together, but when inserted over the leap second, they don't. These {{value,
> writetime}} pairs are sorted by writetime:
> {code}
> (582, 1435708799285000)
> (579, 1435708799339000)
> (583, 1435708799593000)
> (580, 1435708799643000)
> (584, 1435708799897000)
> (581, 1435708799958000)
> {code}
> The values were inserted in increasing order, but their writetimes are in a
> different order because of the repeated second. During the first instance of
> 23:59:59, the values 579, 580, and 581 were inserted at the beginning,
> middle, and end of the second. During the leap second, which is also
> 23:59:59, 582, 583, and 584 were inserted, also at the beginning, middle, and
> end of the second. However, since the two seconds are the same second, they
> appear interleaved with respect to timestamps, as shown above.
> So, should I consider this behavior correct? If not, how should Cassandra
> correctly handle the discontinuity introduced by the insertion of a leap
> second?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
