You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by "Hiller, Dean" <De...@nrel.gov> on 2013/03/04 03:31:24 UTC
no backwards compatibility for thrift in 1.2.2? (we get utter
failure)
I remember huge discussions on backwards compatibility and we have a ton of code using thrift(as do many people out there). We happen to have a startup bean for development that populates data in cassandra for us. We cleared out our QA completely(no data) and ran this….it turns out there seems to be no backwards compatibility as it utterly fails.
>From astyanax point of view, we simply get this (when going back to 1.1.4, everything works fine. I can go down the path of finding out where backwards compatibility breaks but does this mean essentially everyone has to rewrite their applications? OR is there a list of breaking changes that we can't do anymore? Has anyone tried the latest astyanax client with 1.2.2 version?
An unexpected error occured caused by exception RuntimeException:
com.netflix.astyanax.connectionpool.exceptions.NoAvailableHostsException: NoAvailableHostsException: [host=None(0.0.0.0):0, latency=0(0), attempts=0]No hosts to borrow from
Thanks,
Dean
Re: no backwards compatibility for thrift in 1.2.2? (we get utter failure)
Posted by aaron morton <aa...@thelastpickle.com>.
ok, we are talking about all thrift / cli / hector / no CQL tables not been read after an upgrade.
If you can get some repo steps that would be handy.
Cheers
-----------------
Aaron Morton
Freelance Cassandra Developer
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 4/03/2013, at 5:01 AM, "Hiller, Dean" <De...@nrel.gov> wrote:
> For us, this was an issue creating tables in 1.1.4 using thrift, then upgrading to 1.2.2. We did not use cli to create anything. I will try the complete test again today and hopefully get more detail(I didn't know I could not run the same thrift code in 1.2.2 for keyspace creation/table creation)
>
> Thanks,
> Dean
>
> From: aaron morton <aa...@thelastpickle.com>>
> Reply-To: "user@cassandra.apache.org<ma...@cassandra.apache.org>" <us...@cassandra.apache.org>>
> Date: Sunday, March 3, 2013 11:09 PM
> To: "user@cassandra.apache.org<ma...@cassandra.apache.org>" <us...@cassandra.apache.org>>
> Subject: Re: no backwards compatibility for thrift in 1.2.2? (we get utter failure)
>
> Dean,
> Is this an issue with tables created using CQL 3 ?
>
> OR…
>
> An issue with tables created in 1.1.4 using the CLI not been readable after an in place upgrade to 1.2.2 ?
>
> I did a quick test and it worked.
>
> Cheers
>
> -----------------
> Aaron Morton
> Freelance Cassandra Developer
> New Zealand
>
> @aaronmorton
> http://www.thelastpickle.com
>
> On 3/03/2013, at 8:18 PM, Edward Capriolo <ed...@gmail.com>> wrote:
>
> Your other option is to create tables 'WITH COMPACT STORAGE'. Basically if you use COMPACT STORAGE and create tables as you did before.
>
> https://issues.apache.org/jira/browse/CASSANDRA-2995
>
> From an application standpoint, if you can't do sparse, wide rows, you break compatibility with 90% of Cassandra applications. So that rules out almost everything; if you can't provide the same data model, you're creating fragmentation, not pluggability.
>
> I now call Cassandra compact storage 'c*' storage, and I call CQL3 storage 'c*++' storage. See debates on c vs C++ to understand why :).
>
>
> On Sun, Mar 3, 2013 at 9:39 PM, Michael Kjellman <mk...@barracuda.com>> wrote:
> Dean,
>
> I think if you look back through previous mailing list items you'll find
> answers to this already but to summarize:
>
> Tables created prior to 1.2 will continue to work after upgrade. New
> tables created are not exposed by the Thrift API. It is up to client
> developers to upgrade the client to pull the required metadata for
> serialization and deserialization of the data from the System column
> family instead.
>
> I don't know Netflix's time table for an update to Astyanax but I'm sure
> they are working on it. Alternatively, you can also use the Datastax java
> driver in your QA environment for now.
>
> If you only need to access existing column families this shouldn't be an
> issue
>
> On 3/3/13 6:31 PM, "Hiller, Dean" <De...@nrel.gov>> wrote:
>
>> I remember huge discussions on backwards compatibility and we have a ton
>> of code using thrift(as do many people out there). We happen to have a
>> startup bean for development that populates data in cassandra for us. We
>> cleared out our QA completely(no data) and ran thisŠ.it<http://thisŠ.it> turns out there
>> seems to be no backwards compatibility as it utterly fails.
>>
>> From astyanax point of view, we simply get this (when going back to
>> 1.1.4, everything works fine. I can go down the path of finding out
>> where backwards compatibility breaks but does this mean essentially
>> everyone has to rewrite their applications? OR is there a list of
>> breaking changes that we can't do anymore? Has anyone tried the latest
>> astyanax client with 1.2.2 version?
>>
>> An unexpected error occured caused by exception RuntimeException:
>> com.netflix.astyanax.connectionpool.exceptions.NoAvailableHostsException:
>> NoAvailableHostsException: [host=None(0.0.0.0):0, latency=0(0),
>> attempts=0]No hosts to borrow from
>>
>> Thanks,
>> Dean
>
>
> Copy, by Barracuda, helps you store, protect, and share all your amazing
>
> things. Start today: www.copy.com<http://www.copy.com/>.
>
>
grrr. UPGRADE DOES WORK now!!!
Posted by "Hiller, Dean" <De...@nrel.gov>.
It turns out my rpc listen address was localhost. The exception threw me
off as I really should be getting connection refused stuff in there like I
do when I telnet in. I will try to do an astyanax pull request on a fix
for that later.
Dean
On 3/4/13 6:40 AM, "Hiller, Dean" <De...@nrel.gov> wrote:
>I am trying to figure out how to swing a rolling upgrade. My current
>version of astyanax 1.56.18 with cassandra thrift 1.1.1 against an
>upgraded QA(from 1.1.4 to 1.2.2) fails with the below
>exception.......(should
>I be researching why?, or should I be figuring out why 1.2.2 thrift
>doesn't work with cassandra 1.1.4?). I am going to dive into thrift 1.1.1
>with cassandra 1.2.2 and try to debug why that doesn't work as I am
>guessing it should, correct?
>
>Caused by:
>com.netflix.astyanax.connectionpool.exceptions.TransportException:
>TransportException: [host=sdi-prod-03(10.20.5.84):9160, latency=1(7),
>attempts=3]org.apache.thrift.transport.TTransportException
> at
>com.netflix.astyanax.thrift.ThriftConverter.ToConnectionPoolException(Thri
>f
>tConverter.java:197) ~[astyanax-1.56.18.jar:na]
> at
>com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperatio
>n
>Impl.java:60) ~[astyanax-1.56.18.jar:na]
> at
>com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperatio
>n
>Impl.java:27) ~[astyanax-1.56.18.jar:na]
> at
>com.netflix.astyanax.thrift.ThriftSyncConnectionFactoryImpl$1.execute(Thri
>f
>tSyncConnectionFactoryImpl.java:136) ~[astyanax-1.56.18.jar:na]
> at
>com.netflix.astyanax.connectionpool.impl.AbstractExecuteWithFailoverImpl.t
>r
>yOperation(AbstractExecuteWithFailoverImpl.java:69)
>~[astyanax-1.56.18.jar:na]
> at
>com.netflix.astyanax.connectionpool.impl.AbstractHostPartitionConnectionPo
>o
>l.executeWithFailover(AbstractHostPartitionConnectionPool.java:248)
>~[astyanax-1.56.18.jar:na]
> at
>com.netflix.astyanax.thrift.ThriftColumnFamilyQueryImpl$4.execute(ThriftCo
>l
>umnFamilyQueryImpl.java:532) ~[astyanax-1.56.18.jar:na]
> at
>com.alvazan.orm.layer9z.spi.db.cassandra.CursorKeysToRows2.execute(CursorK
>e
>ysToRows2.java:268) ~[playorm.jar:na]
> ... 13 common frames omitted
>Caused by: org.apache.thrift.transport.TTransportException: null
> at
>org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.jav
>a
>:132) ~[libthrift-0.7.0.jar:0.7.0]
> at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
>~[libthrift-0.7.0.jar:0.7.0]
> at
>org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.ja
>v
>a:129) ~[libthrift-0.7.0.jar:0.7.0]
> at
>org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:10
>1
>) ~[libthrift-0.7.0.jar:0.7.0]
> at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
>~[libthrift-0.7.0.jar:0.7.0]
> at
>org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:37
>8
>) ~[libthrift-0.7.0.jar:0.7.0]
> at
>org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:29
>7
>) ~[libthrift-0.7.0.jar:0.7.0]
> at
>org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtoco
>l
>.java:204) ~[libthrift-0.7.0.jar:0.7.0]
> at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:69)
>~[libthrift-0.7.0.jar:0.7.0]
> at
>org.apache.cassandra.thrift.Cassandra$Client.recv_multiget_slice(Cassandra
>.
>java:622) ~[cassandra-thrift-1.1.1.jar:1.1.1]
> at
>org.apache.cassandra.thrift.Cassandra$Client.multiget_slice(Cassandra.java
>:
>606) ~[cassandra-thrift-1.1.1.jar:1.1.1]
> at
>com.netflix.astyanax.thrift.ThriftColumnFamilyQueryImpl$4$1.internalExecut
>e
>(ThriftColumnFamilyQueryImpl.java:538) ~[astyanax-1.56.18.jar:na]
> at
>com.netflix.astyanax.thrift.ThriftColumnFamilyQueryImpl$4$1.internalExecut
>e
>(ThriftColumnFamilyQueryImpl.java:535) ~[astyanax-1.56.18.jar:na]
> at
>com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperatio
>n
>Impl.java:55) ~[astyanax-1.56.18.jar:na]
> ... 19 common frames omitted
>
>
>
>On 3/4/13 6:01 AM, "Hiller, Dean" <De...@nrel.gov> wrote:
>
>>For us, this was an issue creating tables in 1.1.4 using thrift, then
>>upgrading to 1.2.2. We did not use cli to create anything. I will try
>>the complete test again today and hopefully get more detail(I didn't know
>>I could not run the same thrift code in 1.2.2 for keyspace creation/table
>>creation)
>>
>>Thanks,
>>Dean
>>
>>From: aaron morton
>><aa...@thelastpickle.com>>
>>Reply-To: "user@cassandra.apache.org<ma...@cassandra.apache.org>"
>><us...@cassandra.apache.org>>
>>Date: Sunday, March 3, 2013 11:09 PM
>>To: "user@cassandra.apache.org<ma...@cassandra.apache.org>"
>><us...@cassandra.apache.org>>
>>Subject: Re: no backwards compatibility for thrift in 1.2.2? (we get
>>utter failure)
>>
>>Dean,
>>Is this an issue with tables created using CQL 3 ?
>>
>>OR...
>>
>>An issue with tables created in 1.1.4 using the CLI not been readable
>>after an in place upgrade to 1.2.2 ?
>>
>>I did a quick test and it worked.
>>
>>Cheers
>>
>>-----------------
>>Aaron Morton
>>Freelance Cassandra Developer
>>New Zealand
>>
>>@aaronmorton
>>http://www.thelastpickle.com
>>
>>On 3/03/2013, at 8:18 PM, Edward Capriolo
>><ed...@gmail.com>> wrote:
>>
>>Your other option is to create tables 'WITH COMPACT STORAGE'. Basically
>>if you use COMPACT STORAGE and create tables as you did before.
>>
>>https://issues.apache.org/jira/browse/CASSANDRA-2995
>>
>>From an application standpoint, if you can't do sparse, wide rows, you
>>break compatibility with 90% of Cassandra applications. So that rules out
>>almost everything; if you can't provide the same data model, you're
>>creating fragmentation, not pluggability.
>>
>>I now call Cassandra compact storage 'c*' storage, and I call CQL3
>>storage 'c*++' storage. See debates on c vs C++ to understand why :).
>>
>>
>>On Sun, Mar 3, 2013 at 9:39 PM, Michael Kjellman
>><mk...@barracuda.com>> wrote:
>>Dean,
>>
>>I think if you look back through previous mailing list items you'll find
>>answers to this already but to summarize:
>>
>>Tables created prior to 1.2 will continue to work after upgrade. New
>>tables created are not exposed by the Thrift API. It is up to client
>>developers to upgrade the client to pull the required metadata for
>>serialization and deserialization of the data from the System column
>>family instead.
>>
>>I don't know Netflix's time table for an update to Astyanax but I'm sure
>>they are working on it. Alternatively, you can also use the Datastax
>>java
>>driver in your QA environment for now.
>>
>>If you only need to access existing column families this shouldn't be an
>>issue
>>
>>On 3/3/13 6:31 PM, "Hiller, Dean"
>><De...@nrel.gov>> wrote:
>>
>>>I remember huge discussions on backwards compatibility and we have a ton
>>>of code using thrift(as do many people out there). We happen to have a
>>>startup bean for development that populates data in cassandra for us.
>>>We
>>>cleared out our QA completely(no data) and ran thisŠ.it<http://thisŠ.it>
>>>turns out there
>>>seems to be no backwards compatibility as it utterly fails.
>>>
>>>From astyanax point of view, we simply get this (when going back to
>>>1.1.4, everything works fine. I can go down the path of finding out
>>>where backwards compatibility breaks but does this mean essentially
>>>everyone has to rewrite their applications? OR is there a list of
>>>breaking changes that we can't do anymore? Has anyone tried the latest
>>>astyanax client with 1.2.2 version?
>>>
>>>An unexpected error occured caused by exception RuntimeException:
>>>com.netflix.astyanax.connectionpool.exceptions.NoAvailableHostsException
>>>:
>>>NoAvailableHostsException: [host=None(0.0.0.0):0, latency=0(0),
>>>attempts=0]No hosts to borrow from
>>>
>>>Thanks,
>>>Dean
>>
>>
>>Copy, by Barracuda, helps you store, protect, and share all your amazing
>>
>>things. Start today: www.copy.com<http://www.copy.com/>.
>>
>>
>
cassandra 1.2.2 with cassandra thrift 1.1.1? or 1.1.4 with 1.2.2
thrift?
Posted by "Hiller, Dean" <De...@nrel.gov>.
I am trying to figure out how to swing a rolling upgrade. My current
version of astyanax 1.56.18 with cassandra thrift 1.1.1 against an
upgraded QA(from 1.1.4 to 1.2.2) fails with the below exception.......(should
I be researching why?, or should I be figuring out why 1.2.2 thrift
doesn't work with cassandra 1.1.4?). I am going to dive into thrift 1.1.1
with cassandra 1.2.2 and try to debug why that doesn't work as I am
guessing it should, correct?
Caused by:
com.netflix.astyanax.connectionpool.exceptions.TransportException:
TransportException: [host=sdi-prod-03(10.20.5.84):9160, latency=1(7),
attempts=3]org.apache.thrift.transport.TTransportException
at
com.netflix.astyanax.thrift.ThriftConverter.ToConnectionPoolException(Thrif
tConverter.java:197) ~[astyanax-1.56.18.jar:na]
at
com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperation
Impl.java:60) ~[astyanax-1.56.18.jar:na]
at
com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperation
Impl.java:27) ~[astyanax-1.56.18.jar:na]
at
com.netflix.astyanax.thrift.ThriftSyncConnectionFactoryImpl$1.execute(Thrif
tSyncConnectionFactoryImpl.java:136) ~[astyanax-1.56.18.jar:na]
at
com.netflix.astyanax.connectionpool.impl.AbstractExecuteWithFailoverImpl.tr
yOperation(AbstractExecuteWithFailoverImpl.java:69)
~[astyanax-1.56.18.jar:na]
at
com.netflix.astyanax.connectionpool.impl.AbstractHostPartitionConnectionPoo
l.executeWithFailover(AbstractHostPartitionConnectionPool.java:248)
~[astyanax-1.56.18.jar:na]
at
com.netflix.astyanax.thrift.ThriftColumnFamilyQueryImpl$4.execute(ThriftCol
umnFamilyQueryImpl.java:532) ~[astyanax-1.56.18.jar:na]
at
com.alvazan.orm.layer9z.spi.db.cassandra.CursorKeysToRows2.execute(CursorKe
ysToRows2.java:268) ~[playorm.jar:na]
... 13 common frames omitted
Caused by: org.apache.thrift.transport.TTransportException: null
at
org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java
:132) ~[libthrift-0.7.0.jar:0.7.0]
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
~[libthrift-0.7.0.jar:0.7.0]
at
org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.jav
a:129) ~[libthrift-0.7.0.jar:0.7.0]
at
org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:101
) ~[libthrift-0.7.0.jar:0.7.0]
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
~[libthrift-0.7.0.jar:0.7.0]
at
org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:378
) ~[libthrift-0.7.0.jar:0.7.0]
at
org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:297
) ~[libthrift-0.7.0.jar:0.7.0]
at
org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol
.java:204) ~[libthrift-0.7.0.jar:0.7.0]
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:69)
~[libthrift-0.7.0.jar:0.7.0]
at
org.apache.cassandra.thrift.Cassandra$Client.recv_multiget_slice(Cassandra.
java:622) ~[cassandra-thrift-1.1.1.jar:1.1.1]
at
org.apache.cassandra.thrift.Cassandra$Client.multiget_slice(Cassandra.java:
606) ~[cassandra-thrift-1.1.1.jar:1.1.1]
at
com.netflix.astyanax.thrift.ThriftColumnFamilyQueryImpl$4$1.internalExecute
(ThriftColumnFamilyQueryImpl.java:538) ~[astyanax-1.56.18.jar:na]
at
com.netflix.astyanax.thrift.ThriftColumnFamilyQueryImpl$4$1.internalExecute
(ThriftColumnFamilyQueryImpl.java:535) ~[astyanax-1.56.18.jar:na]
at
com.netflix.astyanax.thrift.AbstractOperationImpl.execute(AbstractOperation
Impl.java:55) ~[astyanax-1.56.18.jar:na]
... 19 common frames omitted
On 3/4/13 6:01 AM, "Hiller, Dean" <De...@nrel.gov> wrote:
>For us, this was an issue creating tables in 1.1.4 using thrift, then
>upgrading to 1.2.2. We did not use cli to create anything. I will try
>the complete test again today and hopefully get more detail(I didn't know
>I could not run the same thrift code in 1.2.2 for keyspace creation/table
>creation)
>
>Thanks,
>Dean
>
>From: aaron morton
><aa...@thelastpickle.com>>
>Reply-To: "user@cassandra.apache.org<ma...@cassandra.apache.org>"
><us...@cassandra.apache.org>>
>Date: Sunday, March 3, 2013 11:09 PM
>To: "user@cassandra.apache.org<ma...@cassandra.apache.org>"
><us...@cassandra.apache.org>>
>Subject: Re: no backwards compatibility for thrift in 1.2.2? (we get
>utter failure)
>
>Dean,
>Is this an issue with tables created using CQL 3 ?
>
>OR...
>
>An issue with tables created in 1.1.4 using the CLI not been readable
>after an in place upgrade to 1.2.2 ?
>
>I did a quick test and it worked.
>
>Cheers
>
>-----------------
>Aaron Morton
>Freelance Cassandra Developer
>New Zealand
>
>@aaronmorton
>http://www.thelastpickle.com
>
>On 3/03/2013, at 8:18 PM, Edward Capriolo
><ed...@gmail.com>> wrote:
>
>Your other option is to create tables 'WITH COMPACT STORAGE'. Basically
>if you use COMPACT STORAGE and create tables as you did before.
>
>https://issues.apache.org/jira/browse/CASSANDRA-2995
>
>From an application standpoint, if you can't do sparse, wide rows, you
>break compatibility with 90% of Cassandra applications. So that rules out
>almost everything; if you can't provide the same data model, you're
>creating fragmentation, not pluggability.
>
>I now call Cassandra compact storage 'c*' storage, and I call CQL3
>storage 'c*++' storage. See debates on c vs C++ to understand why :).
>
>
>On Sun, Mar 3, 2013 at 9:39 PM, Michael Kjellman
><mk...@barracuda.com>> wrote:
>Dean,
>
>I think if you look back through previous mailing list items you'll find
>answers to this already but to summarize:
>
>Tables created prior to 1.2 will continue to work after upgrade. New
>tables created are not exposed by the Thrift API. It is up to client
>developers to upgrade the client to pull the required metadata for
>serialization and deserialization of the data from the System column
>family instead.
>
>I don't know Netflix's time table for an update to Astyanax but I'm sure
>they are working on it. Alternatively, you can also use the Datastax java
>driver in your QA environment for now.
>
>If you only need to access existing column families this shouldn't be an
>issue
>
>On 3/3/13 6:31 PM, "Hiller, Dean"
><De...@nrel.gov>> wrote:
>
>>I remember huge discussions on backwards compatibility and we have a ton
>>of code using thrift(as do many people out there). We happen to have a
>>startup bean for development that populates data in cassandra for us. We
>>cleared out our QA completely(no data) and ran thisŠ.it<http://thisŠ.it>
>>turns out there
>>seems to be no backwards compatibility as it utterly fails.
>>
>>From astyanax point of view, we simply get this (when going back to
>>1.1.4, everything works fine. I can go down the path of finding out
>>where backwards compatibility breaks but does this mean essentially
>>everyone has to rewrite their applications? OR is there a list of
>>breaking changes that we can't do anymore? Has anyone tried the latest
>>astyanax client with 1.2.2 version?
>>
>>An unexpected error occured caused by exception RuntimeException:
>>com.netflix.astyanax.connectionpool.exceptions.NoAvailableHostsException:
>>NoAvailableHostsException: [host=None(0.0.0.0):0, latency=0(0),
>>attempts=0]No hosts to borrow from
>>
>>Thanks,
>>Dean
>
>
>Copy, by Barracuda, helps you store, protect, and share all your amazing
>
>things. Start today: www.copy.com<http://www.copy.com/>.
>
>
Re: no backwards compatibility for thrift in 1.2.2? (we get utter
failure)
Posted by "Hiller, Dean" <De...@nrel.gov>.
For us, this was an issue creating tables in 1.1.4 using thrift, then upgrading to 1.2.2. We did not use cli to create anything. I will try the complete test again today and hopefully get more detail(I didn't know I could not run the same thrift code in 1.2.2 for keyspace creation/table creation)
Thanks,
Dean
From: aaron morton <aa...@thelastpickle.com>>
Reply-To: "user@cassandra.apache.org<ma...@cassandra.apache.org>" <us...@cassandra.apache.org>>
Date: Sunday, March 3, 2013 11:09 PM
To: "user@cassandra.apache.org<ma...@cassandra.apache.org>" <us...@cassandra.apache.org>>
Subject: Re: no backwards compatibility for thrift in 1.2.2? (we get utter failure)
Dean,
Is this an issue with tables created using CQL 3 ?
OR…
An issue with tables created in 1.1.4 using the CLI not been readable after an in place upgrade to 1.2.2 ?
I did a quick test and it worked.
Cheers
-----------------
Aaron Morton
Freelance Cassandra Developer
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 3/03/2013, at 8:18 PM, Edward Capriolo <ed...@gmail.com>> wrote:
Your other option is to create tables 'WITH COMPACT STORAGE'. Basically if you use COMPACT STORAGE and create tables as you did before.
https://issues.apache.org/jira/browse/CASSANDRA-2995
>From an application standpoint, if you can't do sparse, wide rows, you break compatibility with 90% of Cassandra applications. So that rules out almost everything; if you can't provide the same data model, you're creating fragmentation, not pluggability.
I now call Cassandra compact storage 'c*' storage, and I call CQL3 storage 'c*++' storage. See debates on c vs C++ to understand why :).
On Sun, Mar 3, 2013 at 9:39 PM, Michael Kjellman <mk...@barracuda.com>> wrote:
Dean,
I think if you look back through previous mailing list items you'll find
answers to this already but to summarize:
Tables created prior to 1.2 will continue to work after upgrade. New
tables created are not exposed by the Thrift API. It is up to client
developers to upgrade the client to pull the required metadata for
serialization and deserialization of the data from the System column
family instead.
I don't know Netflix's time table for an update to Astyanax but I'm sure
they are working on it. Alternatively, you can also use the Datastax java
driver in your QA environment for now.
If you only need to access existing column families this shouldn't be an
issue
On 3/3/13 6:31 PM, "Hiller, Dean" <De...@nrel.gov>> wrote:
>I remember huge discussions on backwards compatibility and we have a ton
>of code using thrift(as do many people out there). We happen to have a
>startup bean for development that populates data in cassandra for us. We
>cleared out our QA completely(no data) and ran thisŠ.it<http://thisŠ.it> turns out there
>seems to be no backwards compatibility as it utterly fails.
>
>From astyanax point of view, we simply get this (when going back to
>1.1.4, everything works fine. I can go down the path of finding out
>where backwards compatibility breaks but does this mean essentially
>everyone has to rewrite their applications? OR is there a list of
>breaking changes that we can't do anymore? Has anyone tried the latest
>astyanax client with 1.2.2 version?
>
>An unexpected error occured caused by exception RuntimeException:
>com.netflix.astyanax.connectionpool.exceptions.NoAvailableHostsException:
>NoAvailableHostsException: [host=None(0.0.0.0):0, latency=0(0),
>attempts=0]No hosts to borrow from
>
>Thanks,
>Dean
Copy, by Barracuda, helps you store, protect, and share all your amazing
things. Start today: www.copy.com<http://www.copy.com/>.
Re: no backwards compatibility for thrift in 1.2.2? (we get utter failure)
Posted by aaron morton <aa...@thelastpickle.com>.
Dean,
Is this an issue with tables created using CQL 3 ?
OR…
An issue with tables created in 1.1.4 using the CLI not been readable after an in place upgrade to 1.2.2 ?
I did a quick test and it worked.
Cheers
-----------------
Aaron Morton
Freelance Cassandra Developer
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 3/03/2013, at 8:18 PM, Edward Capriolo <ed...@gmail.com> wrote:
> Your other option is to create tables 'WITH COMPACT STORAGE'. Basically if you use COMPACT STORAGE and create tables as you did before.
>
> https://issues.apache.org/jira/browse/CASSANDRA-2995
>
> From an application standpoint, if you can't do sparse, wide rows, you break compatibility with 90% of Cassandra applications. So that rules out almost everything; if you can't provide the same data model, you're creating fragmentation, not pluggability.
>
> I now call Cassandra compact storage 'c*' storage, and I call CQL3 storage 'c*++' storage. See debates on c vs C++ to understand why :).
>
>
> On Sun, Mar 3, 2013 at 9:39 PM, Michael Kjellman <mk...@barracuda.com> wrote:
> Dean,
>
> I think if you look back through previous mailing list items you'll find
> answers to this already but to summarize:
>
> Tables created prior to 1.2 will continue to work after upgrade. New
> tables created are not exposed by the Thrift API. It is up to client
> developers to upgrade the client to pull the required metadata for
> serialization and deserialization of the data from the System column
> family instead.
>
> I don't know Netflix's time table for an update to Astyanax but I'm sure
> they are working on it. Alternatively, you can also use the Datastax java
> driver in your QA environment for now.
>
> If you only need to access existing column families this shouldn't be an
> issue
>
> On 3/3/13 6:31 PM, "Hiller, Dean" <De...@nrel.gov> wrote:
>
> >I remember huge discussions on backwards compatibility and we have a ton
> >of code using thrift(as do many people out there). We happen to have a
> >startup bean for development that populates data in cassandra for us. We
> >cleared out our QA completely(no data) and ran thisŠ.it turns out there
> >seems to be no backwards compatibility as it utterly fails.
> >
> >From astyanax point of view, we simply get this (when going back to
> >1.1.4, everything works fine. I can go down the path of finding out
> >where backwards compatibility breaks but does this mean essentially
> >everyone has to rewrite their applications? OR is there a list of
> >breaking changes that we can't do anymore? Has anyone tried the latest
> >astyanax client with 1.2.2 version?
> >
> >An unexpected error occured caused by exception RuntimeException:
> >com.netflix.astyanax.connectionpool.exceptions.NoAvailableHostsException:
> >NoAvailableHostsException: [host=None(0.0.0.0):0, latency=0(0),
> >attempts=0]No hosts to borrow from
> >
> >Thanks,
> >Dean
>
>
> Copy, by Barracuda, helps you store, protect, and share all your amazing
>
> things. Start today: www.copy.com.
>
Re: no backwards compatibility for thrift in 1.2.2? (we get utter failure)
Posted by Edward Capriolo <ed...@gmail.com>.
Your other option is to create tables 'WITH COMPACT STORAGE'. Basically if
you use COMPACT STORAGE and create tables as you did before.
https://issues.apache.org/jira/browse/CASSANDRA-2995
>From an application standpoint, if you can't do sparse, wide rows, you
break compatibility with 90% of Cassandra applications. So that rules out
almost everything; if you can't provide the same data model, you're
creating fragmentation, not pluggability.
I now call Cassandra compact storage 'c*' storage, and I call CQL3 storage
'c*++' storage. See debates on c vs C++ to understand why :).
On Sun, Mar 3, 2013 at 9:39 PM, Michael Kjellman <mk...@barracuda.com>wrote:
> Dean,
>
> I think if you look back through previous mailing list items you'll find
> answers to this already but to summarize:
>
> Tables created prior to 1.2 will continue to work after upgrade. New
> tables created are not exposed by the Thrift API. It is up to client
> developers to upgrade the client to pull the required metadata for
> serialization and deserialization of the data from the System column
> family instead.
>
> I don't know Netflix's time table for an update to Astyanax but I'm sure
> they are working on it. Alternatively, you can also use the Datastax java
> driver in your QA environment for now.
>
> If you only need to access existing column families this shouldn't be an
> issue
>
> On 3/3/13 6:31 PM, "Hiller, Dean" <De...@nrel.gov> wrote:
>
> >I remember huge discussions on backwards compatibility and we have a ton
> >of code using thrift(as do many people out there). We happen to have a
> >startup bean for development that populates data in cassandra for us. We
> >cleared out our QA completely(no data) and ran thisŠ.it turns out there
> >seems to be no backwards compatibility as it utterly fails.
> >
> >From astyanax point of view, we simply get this (when going back to
> >1.1.4, everything works fine. I can go down the path of finding out
> >where backwards compatibility breaks but does this mean essentially
> >everyone has to rewrite their applications? OR is there a list of
> >breaking changes that we can't do anymore? Has anyone tried the latest
> >astyanax client with 1.2.2 version?
> >
> >An unexpected error occured caused by exception RuntimeException:
> >com.netflix.astyanax.connectionpool.exceptions.NoAvailableHostsException:
> >NoAvailableHostsException: [host=None(0.0.0.0):0, latency=0(0),
> >attempts=0]No hosts to borrow from
> >
> >Thanks,
> >Dean
>
>
> Copy, by Barracuda, helps you store, protect, and share all your amazing
>
> things. Start today: www.copy.com.
>
Re: no backwards compatibility for thrift in 1.2.2? (we get utter
failure)
Posted by "Hiller, Dean" <De...@nrel.gov>.
It was an issue for existing tables as in QA, I ran an upgrade from 1.1.4
with simple data and then after 1.2.2, could not access stuff, ended up
with timeouts. After that I cleared everything and just started a 1.2.2
as I wanted to see if just a base install of 1.2.2 with no upgrade worked
which it did not.
Ie. The backwards compatibility does not seem to be working.
Any ideas on how I could even attempt to resolve this? We really want to
get to LCS and rumor is it is much slower in 1.1.x than 1.2.x on some post
I read
http://mail-archives.apache.org/mod_mbox/cassandra-user/201302.mbox/%3C87D9
68E5-56A0-4DA7-8676-BA90FF376761@yahoo.com%3E
Thanks,
Dean
On 3/3/13 7:39 PM, "Michael Kjellman" <mk...@barracuda.com> wrote:
>Dean,
>
>I think if you look back through previous mailing list items you'll find
>answers to this already but to summarize:
>
>Tables created prior to 1.2 will continue to work after upgrade. New
>tables created are not exposed by the Thrift API. It is up to client
>developers to upgrade the client to pull the required metadata for
>serialization and deserialization of the data from the System column
>family instead.
>
>I don't know Netflix's time table for an update to Astyanax but I'm sure
>they are working on it. Alternatively, you can also use the Datastax java
>driver in your QA environment for now.
>
>If you only need to access existing column families this shouldn't be an
>issue
>
>On 3/3/13 6:31 PM, "Hiller, Dean" <De...@nrel.gov> wrote:
>
>>I remember huge discussions on backwards compatibility and we have a ton
>>of code using thrift(as do many people out there). We happen to have a
>>startup bean for development that populates data in cassandra for us. We
>>cleared out our QA completely(no data) and ran thisŠ.it turns out there
>>seems to be no backwards compatibility as it utterly fails.
>>
>>From astyanax point of view, we simply get this (when going back to
>>1.1.4, everything works fine. I can go down the path of finding out
>>where backwards compatibility breaks but does this mean essentially
>>everyone has to rewrite their applications? OR is there a list of
>>breaking changes that we can't do anymore? Has anyone tried the latest
>>astyanax client with 1.2.2 version?
>>
>>An unexpected error occured caused by exception RuntimeException:
>>com.netflix.astyanax.connectionpool.exceptions.NoAvailableHostsException:
>>NoAvailableHostsException: [host=None(0.0.0.0):0, latency=0(0),
>>attempts=0]No hosts to borrow from
>>
>>Thanks,
>>Dean
>
>
>Copy, by Barracuda, helps you store, protect, and share all your amazing
>
>things. Start today: www.copy.com.
Re: no backwards compatibility for thrift in 1.2.2? (we get utter
failure)
Posted by Michael Kjellman <mk...@barracuda.com>.
Dean,
I think if you look back through previous mailing list items you'll find
answers to this already but to summarize:
Tables created prior to 1.2 will continue to work after upgrade. New
tables created are not exposed by the Thrift API. It is up to client
developers to upgrade the client to pull the required metadata for
serialization and deserialization of the data from the System column
family instead.
I don't know Netflix's time table for an update to Astyanax but I'm sure
they are working on it. Alternatively, you can also use the Datastax java
driver in your QA environment for now.
If you only need to access existing column families this shouldn't be an
issue
On 3/3/13 6:31 PM, "Hiller, Dean" <De...@nrel.gov> wrote:
>I remember huge discussions on backwards compatibility and we have a ton
>of code using thrift(as do many people out there). We happen to have a
>startup bean for development that populates data in cassandra for us. We
>cleared out our QA completely(no data) and ran thisŠ.it turns out there
>seems to be no backwards compatibility as it utterly fails.
>
>From astyanax point of view, we simply get this (when going back to
>1.1.4, everything works fine. I can go down the path of finding out
>where backwards compatibility breaks but does this mean essentially
>everyone has to rewrite their applications? OR is there a list of
>breaking changes that we can't do anymore? Has anyone tried the latest
>astyanax client with 1.2.2 version?
>
>An unexpected error occured caused by exception RuntimeException:
>com.netflix.astyanax.connectionpool.exceptions.NoAvailableHostsException:
>NoAvailableHostsException: [host=None(0.0.0.0):0, latency=0(0),
>attempts=0]No hosts to borrow from
>
>Thanks,
>Dean
Copy, by Barracuda, helps you store, protect, and share all your amazing
things. Start today: www.copy.com.