On Wed, Jul 23, 2014 at 1:53 AM, Robert Coli wrote:
> On Tue, Jul 22, 2014 at 1:53 AM, Ben Hood <0x6e6...@gmail.com> wrote:
> Indeed, reading up on the issue (and discussing it with folks) there are a
> number of mitigating factors, most significantly driver workarounds use of
> TimeUUIDs, which m
On Wed, Jul 23, 2014 at 1:53 AM, Robert Coli wrote:
> On Tue, Jul 22, 2014 at 1:53 AM, Ben Hood <0x6e6...@gmail.com> wrote:
> In this particular case, the answer to "why not" involves the idea that one
> needs to be able to test with a driver in order to expose it, and currently
> (as I understand
On Tue, Jul 22, 2014 at 1:53 AM, Ben Hood <0x6e6...@gmail.com> wrote:
> As Karl has suggested, client driver maintainers have opted to
> workaround the issue.
Indeed, reading up on the issue (and discussing it with folks) there are a
number of mitigating factors, most significantly driver workar
On Tue, Jul 22, 2014 at 1:26 AM, Robert Coli wrote:
> I'm pretty sure reversed comparator timestamps are a common type of schema,
> given that there are blog posts recommending their use, so I struggle to
> understand how this was not detected by unit tests.
As Karl has suggested, client driver m
I did not include unit tests in my patch. I think many people did not run into
this issue because many Cassandra clients handle the DateType when found as a
CUSTOM type.
-Karl
> On Jul 21, 2014, at 8:26 PM, Robert Coli wrote:
>
>> On Mon, Jul 21, 2014 at 1:58 AM, Ben Hood <0x6e6...@gmail.com
On Mon, Jul 21, 2014 at 1:58 AM, Ben Hood <0x6e6...@gmail.com> wrote:
> On Sat, Jul 19, 2014 at 7:35 PM, Karl Rieb wrote:
> > Can now be followed at:
> > https://issues.apache.org/jira/browse/CASSANDRA-7576.
>
> Nice work! Finally we have a proper solution to this issue, so well done
> to you.
>
On Sat, Jul 19, 2014 at 7:35 PM, Karl Rieb wrote:
> Can now be followed at:
> https://issues.apache.org/jira/browse/CASSANDRA-7576.
Nice work! Finally we have a proper solution to this issue, so well done to you.
Can now be followed at: https://issues.apache.org/jira/browse/CASSANDRA-7576
.
On Sat, Jul 19, 2014 at 1:03 PM, Karl Rieb wrote:
> Will do!
>
> On Jul 19, 2014, at 11:22 AM, Robert Stupp wrote:
>
> Can you submit a ticket in C* JIRA at issues.apache.org?
>
> --
> Sent from my iPhone
>
> Am 19.
Will do!
> On Jul 19, 2014, at 11:22 AM, Robert Stupp 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 :
>>
>> Ben! I think I have an idea of exactly where the bug is!
>>
>> I did some more searchi
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 :
>
> 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
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.cassand
On Fri, Jul 18, 2014 at 3:03 PM, Karl Rieb 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
Thanks Ben,
I found that thread, but my concern is the inconsistency on the Cassandra side.
Why is the protocol ID correct for some tables but not others? Why does it work
when I do a clean install on a new 2.0.x cluster? The bug seems to be on the
Cassandra side and the clients seem to just b
On Fri, Jul 18, 2014 at 3:38 AM, Karl Rieb wrote:
> Any suggestions on what is going on or how to fix it?
I'm not sure how much this will help, but one of the gocql users
reported similar symptoms when upgrading to 2.0.6. We ended up
applying a client side patch to address the issue, the details
Hi,
I've been testing an in-place upgrade of a 1.2.11 cluster to 2.0.9. The
1.2.11 nodes all have a schema defined through CQL with existing data
before I perform the rolling upgrade. While the upgrade is in progress,
services are continuing to read and write data to the cluster (strictly
using
15 matches
Mail list logo
