cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Stupp <sn...@snazy.de>
Subject Re: DataType protocol ID error for TIMESTAMPs when upgrading from 1.2.11 to 2.0.9
Date Sat, 19 Jul 2014 15:22:30 GMT
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