cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Dusbabek (JIRA)" <>
Subject [jira] Updated: (CASSANDRA-1548) renaming a keyspace, then trying to use original name again makes errorations
Date Tue, 28 Sep 2010 07:09:33 GMT


Gary Dusbabek updated CASSANDRA-1548:

    Attachment: v1-0001-ensure-that-a-table-unloads-CFS-instances-when-they-ar.txt

> renaming a keyspace, then trying to use original name again makes errorations
> -----------------------------------------------------------------------------
>                 Key: CASSANDRA-1548
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.7 beta 2
>         Environment: encountered on Debian squeeze, with cassandra from HEAD (r1001931).
 effects can be seen with both Telephus and Pycassa as clients; probably any.
>            Reporter: paul cannon
>            Assignee: Gary Dusbabek
>            Priority: Minor
>             Fix For: 0.7.0
>         Attachments:, v1-0001-ensure-that-a-table-unloads-CFS-instances-when-they-ar.txt
> My test case does the following:
> * Create a keyspace with at least one CF in it.
> * Rename that keyspace
> * Create a new keyspace with the same original name, containing a CF with the same name
as earlier.
> The second keyspace creation receives an error (although the keyspace does get created):
> {{ org.apache.cassandra.db:type=ColumnFamilies,keyspace=keyspacename,columnfamily=cfname}}
> After that point, trying to do almost anything with the new keyspace will generate the
same error- even trying to drop it. This persists until cassandra itself is restarted.
> One supposes that some JMX thing is lacking reregistration upon keyspace rename.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message