On Wed, Oct 20, 2010 at 15:53, Aaron Morton <aa...@thelastpickle.com> wrote: > I was helping a guy who in the end had a mixed beta1 and beta2 > cluster http://www.mail-archive.com/u...@cassandra.apache.org/msg06661.html > I had a look around the code and have a couple of questions, just for my > understanding. > When ReadResponseSerialize is called to deserialize the response from a > node, it calls the RowSerializer which uses the ColumnFamilySerializer. If > the CfId in the row is not known on the node > a UnserializableColumnFamilyException is thrown. It's an IOException sub > class and the error is treated as an Internal Error by the thrift generated > Cassandra server. > The read message sent to the node contains the Keyspace+CF names, and it > returns it's CfID in the response. > It looks like if a node somehow has a different/bad schema it can cause > reads to fail. Is this correct?
Seems like the right thing to do. > Could it's response be ignored if the read > still meets the CL? I haven't made up my mind about this one. On one hand, it would be good to let the user know that things aren't good in the cluster. But on the other hand, the cluster is still healthy enough to return good results, maybe we should let it. I lean towards the latter. > Next question was how nodes could ever get to have a different CfId for the > same Keyspace+CF pair? It looks like the the CfId is never changed, so it > would only happen if two node were each given a schema update and could not > communicate it with each other. It would have to be as a result of two migrations. When migrations are exported to other nodes, the cfid used is the value that is sent, not the next counter value on the host receiving the migration. > Am guessing the whole scenario is "unsupported" just trying to understand > whats happening. Makes me scratch my head too. Gary. > Thanks > Aaron > >
