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 <0x6e6...@gmail.com> wrote:
> On Fri, Jul 18, 2014 at 3:03 PM, Karl Rieb <karl.r...@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.
>
