FWIW I was able to work around this problem by having my code run the
following loop:

while (the index doesn't exit and we haven't hit our limit of number of tries):
    try to create the index
    read from system.schema_columns to see if the index exists
    if so, then break
    if not, pause 5 seconds

This loop took three iterations to create the index.

Is this expected?  This seems really weird!

Best regards,
Clint

On Mon, Jul 14, 2014 at 5:54 PM, Clint Kelly <clint.ke...@gmail.com> wrote:
> BTW I have seen this using versions 2.0.1 and 2.0.3 of the java driver
> on a three-node cluster with DSE 4.5.
>
> On Mon, Jul 14, 2014 at 5:51 PM, Clint Kelly <clint.ke...@gmail.com> wrote:
>> Hi everyone,
>>
>> I have some code that I've been fiddling with today that uses the
>> DataStax Java driver to create a table and then create a secondary
>> index on a column in that table.  I've testing this code fairly
>> thoroughly on a single-node Cassandra instance on my laptop and in
>> unit test (using the CassandraDaemon).
>>
>> When running on a three-node cluster, however, I see strange behavior.
>> Although my table always gets created, the secondary index often does
>> not!  If I delete the table and then create it again (through the same
>> code that I've written), I've never seen the index fail to appear the
>> second time.
>>
>> Does anyone have any idea what to look for here?  I have no experience
>> working on a Cassandra cluster and I wonder if maybe I am doing
>> something dumb (I basically just installed DSE and started up the
>> three nodes and that was it).  I don't see anything that looks unusual
>> in OpsCenter for DSE.
>>
>> The only thing I've noticed is that the presence of output like the
>> following from my program after executing the command to create the
>> index is perfectly correlated with successful creation of the index:
>>
>> 14/07/14 17:40:01 DEBUG com.datastax.driver.core.Cluster: Received
>> event EVENT CREATED kiji_retail2.t_model_repo, scheduling delivery
>> 14/07/14 17:40:01 DEBUG com.datastax.driver.core.ControlConnection:
>> [Control connection] Refreshing schema for kiji_retail2
>> 14/07/14 17:40:01 DEBUG com.datastax.driver.core.Cluster: Refreshing
>> schema for kiji_retail2
>> 14/07/14 17:40:01 DEBUG com.datastax.driver.core.ControlConnection:
>> Checking for schema agreement: versions are
>> [9a8d72f9-e384-3aa8-bc85-185e2c303ade,
>> b309518a-35d2-3790-bb66-ea39bb0d188c]
>> 14/07/14 17:40:02 DEBUG com.datastax.driver.core.ControlConnection:
>> Checking for schema agreement: versions are
>> [9a8d72f9-e384-3aa8-bc85-185e2c303ade,
>> b309518a-35d2-3790-bb66-ea39bb0d188c]
>> 14/07/14 17:40:02 DEBUG com.datastax.driver.core.ControlConnection:
>> Checking for schema agreement: versions are
>> [9a8d72f9-e384-3aa8-bc85-185e2c303ade,
>> b309518a-35d2-3790-bb66-ea39bb0d188c]
>> 14/07/14 17:40:02 DEBUG com.datastax.driver.core.ControlConnection:
>> Checking for schema agreement: versions are
>> [9a8d72f9-e384-3aa8-bc85-185e2c303ade,
>> b309518a-35d2-3790-bb66-ea39bb0d188c]
>> 14/07/14 17:40:02 DEBUG com.datastax.driver.core.ControlConnection:
>> Checking for schema agreement: versions are
>> [b309518a-35d2-3790-bb66-ea39bb0d188c]
>>
>> If anyone can give me a hand, I would really appreciate it.  I am out of 
>> ideas!
>>
>> Best regards,
>> Clint

Reply via email to