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" <dean.hil...@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<mailto:aa...@thelastpickle.com>>
>Reply-To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>"
><user@cassandra.apache.org<mailto:user@cassandra.apache.org>>
>Date: Sunday, March 3, 2013 11:09 PM
>To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>"
><user@cassandra.apache.org<mailto:user@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
><edlinuxg...@gmail.com<mailto:edlinuxg...@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
><mkjell...@barracuda.com<mailto:mkjell...@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"
><dean.hil...@nrel.gov<mailto:dean.hil...@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/>.
>
>
