[
https://issues.apache.org/jira/browse/CASSANDRA-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211524#comment-13211524
]
Pavel Yaskevich edited comment on CASSANDRA-3804 at 2/19/12 8:13 PM:
---------------------------------------------------------------------
I have found the problem with EOFException in Truncate - it was caused by
MIGRATION_REQUEST misinterpreted by 1.0 as TRUNCATE message, I have added a
check into MM.rectifySchema(UUID, InetAddress) to skip that request if node
with changed schema is older than 1.1. Two patches in combination now return no
exceptions but node 1.0 without patch would still throw
UnsupportedOperationException because Gossiper always propagates passive schema
announce.
Edit: I have also changed "Can't accept schema migrations from Cassandra
versions previous to 1.1, please update first." in 1.1 to be log error instead
of IOException.
was (Author: xedin):
I have found the problem with EOFException in Truncate - it was caused by
MIGRATION_REQUEST misinterpreted by 1.0 as TRUNCATE message, I have added a
check into MM.rectifySchema(UUID, InetAddress) to skip that request if node
with changed schema is older than 1.1. Two patches in combination now return no
exceptions but node 1.0 without patch would still throw
UnsupportedOperationException because Gossiper always propagates passive schema
announce.
> 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.0
> Environment: ubuntu, cluster set up with ccm.
> Reporter: Tyler Patterson
> Assignee: Pavel Yaskevich
> Fix For: 1.1.0
>
> Attachments: CASSANDRA-3804-1.1-v2.patch, CASSANDRA-3804-1.1.patch,
> CASSANDRA-3804.patch, node1.log, node2.log
>
>
> 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:
> [email protected]: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
