Avoid this subject, giving it a second thought, There is no reason to put a
column a TTL value that goes past a year, and this problem will only appear
after the year 2038.

I need to stop drinking coffee.

On Wed, Jan 19, 2011 at 7:08 PM, Javier Canillas
<javier.canil...@gmail.com>wrote:

> I have been working on Aquiles for some time, and some of the people that
> is actually using my client to consume Cassandra's services (lastest
> version on Cassandra 0.7.0) has followed me an issue. Básically, they were
> trying to submit a new column with a TTL value of 852282524, and everytime
> they tried to insert int, the following Thrift error was going back to them:
>
> Thrift.TApplicationException: Internal error processing insert
> at Apache.Cassandra.Cassandra.Client.recv_insert() in
> D:\apache-cassandra-0.7.0-beta3\interface\gen-csharp\Apache\Cassandra\Cassandra.cs:line
> 485
> at Apache.Cassandra.Cassandra.Client.insert(Byte[] key, ColumnParent
> column_parent, Column column, ConsistencyLevel consistency_level) in
> D:\apache-cassandra-0.7.0-beta3\interface\gen-csharp\Apache\Cassandra\Cassandra.cs:line
> 463
>
> And the log within Cassandra was:
>
> ERROR [pool-1-thread-45] 2011-01-16 19:03:35,514 Cassandra.java (line 2960)
> Internal error processing insert
> java.lang.AssertionError: -2147462157
> at org.apache.cassandra.db.ExpiringColumn.<init>(ExpiringColumn.java:57)
> at org.apache.cassandra.db.ExpiringColumn.<init>(ExpiringColumn.java:50)
> at org.apache.cassandra.db.ColumnFamily.addColumn(ColumnFamily.java:167)
> at org.apache.cassandra.db.RowMutation.add(RowMutation.java:151)
> at
> org.apache.cassandra.thrift.CassandraServer.insert(CassandraServer.java:343)
> at
> org.apache.cassandra.thrift.Cassandra$Processor$insert.process(Cassandra.java:2952)
> at
> org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2555)
> at
> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:167)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
>
> I know that a TTL value of 9864 days is way too long, but after stepping
> into the code, I found out the following:
>
> public ExpiringColumn(ByteBuffer name, ByteBuffer value, long timestamp,
> int timeToLive)
>     {
>       this(name, value, timestamp, timeToLive, (int)
> (System.currentTimeMillis() / 1000) + timeToLive);
>     }
>
> So, the constructor of ExpiringColumn was basically converting a long into
> an int and then adding the TTL value for that column. this value is the
> placed on localExpirationTime which is used to check to see if the Column is
> mark for deletation. This last variable is defined as integer.
>
> So, after doing some math and rechecking the code, I think I have come
> across a serious problem which means that, as time passes, the maximum
> posible TTL value that might be set to an Expiring column must be each
> second lower than before.
>
> This is a huge limitation, as for now (using System.currentTimeMillis()
> from my machine) the maximum posible TTL value is 9861 days (851990400
> seconds) now, but tomorrow it will be 9860 days and so on. So each day we
> came closer to this issue.
>
> I think that a good solution is changing the localExpirationTime from int
> to long and, avoid converting a long value to its integer representation.
>
> Just give me your thoughts about this.
>
> Javier Canillas
>
>
>
>
>
>
>

Reply via email to