Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 30 Jan 2012 16:00:10 +0000 (UTC)
From: "Pavel Yaskevich (Commented) (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <1937043758.7816.1327939210515.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <2062531800.3570.1327723392980.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CASSANDRA-3804) upgrade problems from 1.0 to
 trunk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196194#comment-13196194 ] 

Pavel Yaskevich commented on CASSANDRA-3804:
--------------------------------------------

bq. "Never come to agreement" is fine as long as normal reads/writes (against existing CFs) continue to work.

reads/writes should work against existing CFs. failure from description and first comment are related to the way how cassandra-dtest works because it tries to re-create schema for every test-case which won't work for in the mixed version cluster, if, for example, it was to create a ColumnFamily before updating one of the nodes to trunk, reads/writes to that ColumnFamily would still work after update even tho nodes will be in schema disagreement.
                
> upgrade problems from 1.0 to trunk
> ----------------------------------
>
>                 Key: CASSANDRA-3804
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3804
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1
>         Environment: ubuntu, cluster set up with ccm.
>            Reporter: Tyler Patterson
>            Assignee: Pavel Yaskevich
>             Fix For: 1.1
>
>
> A 3-node cluster is on version 0.8.9, 1.0.6, or 1.0.7 and then one and only one node is taken down, upgraded to trunk, and started again. An rpc timeout exception happens if counter-add operations are done. It usually takes between 1 and 500 add operations before the failure occurs. The failure seems to happen sooner if the coordinator node is NOT the one that was upgraded. Here is the error: 
> {code}
> ======================================================================
> ERROR: counter_upgrade_test.TestCounterUpgrade.counter_upgrade_test
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/lib/pymodules/python2.7/nose/case.py", line 187, in runTest
>     self.test(*self.arg)
>   File "/home/tahooie/cassandra-dtest/counter_upgrade_test.py", line 50, in counter_upgrade_test
>     cursor.execute("UPDATE counters SET row = row+1 where key='a'")
>   File "/usr/local/lib/python2.7/dist-packages/cql/cursor.py", line 96, in execute
>     raise cql.OperationalError("Request did not complete within rpc_timeout.")
> OperationalError: Request did not complete within rpc_timeout.
> {code}
> A script has been added to cassandra-dtest (counter_upgrade_test.py) to demonstrate the failure. The newest version of CCM is required to run the test. It is available here if it hasn't yet been pulled: git@github.com:tpatterson/ccm.git

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira