[
https://issues.apache.org/jira/browse/CASSANDRA-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13209486#comment-13209486
]
Sylvain Lebresne commented on CASSANDRA-3804:
---------------------------------------------
Reattaching the two logs with only the 1.1 patch applied. Putting asides all
the truncation related EOFException for now:
* on node1 (the 1.1 node), we do see a "Can't accept schema migrations from
Cassandra versions previous to 1.1, please update first", though I suppose it
would be nice to avoid the 'Fatal exception' and stacktrace that tends to
scare people.
* on node2, we still have "UnsupportedOperationException: Not a time-based
UUID" exceptions.
That being said, even if we fix all those exceptions (which we should, there no
question on that), it is still the case that the schema change is applied to
the 1.0 nodes and no error is returned to the user (that is, outside of the log
file), but the added column family is not really usable (the user will get
timeouts) at least until the cluster upgrade is complete. Even if the user do
watch the log and see the error (and will probably assume the creation failed),
the column family is still created. That's not really user friendly. So I still
think it would be a good idea to add code to 1.0 and 1.1 to refuse upfront
schema changes when the cluster is known to have mixed pre-1.1/post-1.1
versions. That don't necessarily mean we would *require* an upgrade to 1.0.8+
before upgrading to 1.1, but it would mean that for all those that does upgrade
from 1.0.8 (possibly a majority of users), we're being more user friendly.
> 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.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
