cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Rieb <karl.r...@gmail.com>
Subject Re: DataType protocol ID error for TIMESTAMPs when upgrading from 1.2.11 to 2.0.9
Date Sat, 19 Jul 2014 18:35:12 GMT
Can now be followed at: https://issues.apache.org/jira/browse/CASSANDRA-7576
.


On Sat, Jul 19, 2014 at 1:03 PM, Karl Rieb <karl.rieb@gmail.com> wrote:

> Will do!
>
> On Jul 19, 2014, at 11:22 AM, Robert Stupp <snazy@snazy.de> wrote:
>
> Can you submit a ticket in C* JIRA at issues.apache.org?
>
> --
> Sent from my iPhone
>
> Am 19.07.2014 um 16:45 schrieb Karl Rieb <karl.rieb@gmail.com>:
>
> Ben! I think I have an idea of exactly where the bug is!
>
> I did some more searching and discovered the difference that causes some
> tables to produce the wrong type and others to be okay: *the tables with
> the wrong type reverse the ordering of the timestamp column*.
>
> The bug is in
> org.apache.cassandra.transport.DataType:fromType(AbstractType):
>
>     public static Pair<DataType, Object> fromType(AbstractType type)
>     {
>         // For CQL3 clients, ReversedType is an implementation detail and
> they
>         // shouldn't have to care about it.
>         if (type instanceof ReversedType)
>             type = ((ReversedType)type).baseType;
>         // For compatibility sake, we still return DateType as the
> timestamp type in resultSet metadata (#5723)
>         else if (type instanceof DateType)
>             type = TimestampType.instance;
>
>         DataType dt = dataTypeMap.get(type);
>         if (dt == null)
>         {
>             if (type.isCollection())
>             {
>                 if (type instanceof ListType)
>                 {
>                     return Pair.<DataType, Object>create(LIST,
> ((ListType)type).elements);
>                 }
>                 else if (type instanceof MapType)
>                 {
>                     MapType mt = (MapType)type;
>                     return Pair.<DataType, Object>create(MAP,
> Arrays.asList(mt.keys, mt.values));
>                 }
>                 else
>                 {
>                     assert type instanceof SetType;
>                     return Pair.<DataType, Object>create(SET,
> ((SetType)type).elements);
>                 }
>             }
>             return Pair.<DataType, Object>create(CUSTOM, type.toString());
>         }
>         else
>         {
>             return Pair.create(dt, null);
>         }
>     }
>
> The issue is the "else if", which does not check the base type of the
> reversed column:
>
>         if (type instanceof ReversedType)
>             type = ((ReversedType)type).baseType;
>         // For compatibility sake, we still return DateType as the
> timestamp type in resultSet metadata (#5723)
>         *else if* (type instanceof DateType)
>             type = TimestampType.instance;
>
> The "else" should be removed to make it just:
>
>         if (type instanceof ReversedType)
>             type = ((ReversedType)type).baseType;
>         // For compatibility sake, we still return DateType as the
> timestamp type in resultSet metadata (#5723)
>         *if* (type instanceof DateType)
>             type = TimestampType.instance;
>
> This way we do a check for DataType on the base type of reversed columns!
>
> I applied the fix to my 2.0.9 cassandra node and the errors go away!!!!!
>
> Could you guys please make this single-word fix?
>
> -Karl
>
>
>
> On Fri, Jul 18, 2014 at 1:30 PM, Ben Hood <0x6e6562@gmail.com> wrote:
>
>> On Fri, Jul 18, 2014 at 3:03 PM, Karl Rieb <karl.rieb@gmail.com> wrote:
>> > Why is the protocol ID correct for some tables but not others?
>>
>> I have no idea.
>>
>> > Why does it work when I do a clean install on a new 2.0.x cluster?
>>
>> I still have no idea.
>>
>> > The bug seems to be on the Cassandra side and the clients seem to just
>> be providing patches to these issues.
>>
>> It was reported to the Cassandra list, but there was no answer,
>> potentially because the query was sent to the wrong list, but I don't
>> really know. Maybe it should have gone into Jira, but it's unclear as
>> to whether this is a client or a server issue.
>>
>> In any case, it didn't look like the server behavior was going to
>> change any time soon, so we just took the pragmatic approach in gocql
>> and worked around the issue.
>>
>> > I will post to the Datastax java driver mailing list and see if they
>> are willing to add a patch.
>>
>> That sounds like a good idea, seeing as the workaround has been tested
>> before.
>>
>> Sorry to be of little help to you.
>>
>
>

Mime
View raw message