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" <dean.hil...@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" <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/>. >> >> >
