It's a bug.
In SSTableDeletingReference, it try this operation
components.remove(Component.DATA);
before
STable.delete(desc, components);
However, the components was reference to the components object which was
created inside SSTable by
this.components = Collections.unmodifiableSet(dataComponents);
As you can see, you can't try the remove operation on that componets object.
If I add a try block and output exception around the
components.remove(Component.DATA), I got this.
java.lang.UnsupportedOperationException
at java.util.Collections$UnmodifiableCollection.remove(Unknown
Source)
at
org.apache.cassandra.io.sstable.SSTableDeletingReference$CleanupTask.run(SSTableDeletingReference.java:103)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown
Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
Source)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
Source)
at
org.apache.cassandra.concurrent.RetryingScheduledThreadPoolExecutor$LoggingScheduledFuture.run(RetryingScheduledThreadPoolExecutor.java:81)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
at java.lang.Thread.run(Unknown Source)
Regards,
Chen
On Tue, Jan 25, 2011 at 4:21 PM, Jonathan Ellis <jbel...@gmail.com> wrote:
> the other component types are deleted by this line:
>
> SSTable.delete(desc, components);
>
> On Tue, Jan 25, 2011 at 3:11 PM, Ching-Cheng Chen
> <cc...@evidentsoftware.com> wrote:
> > Nope, no exception at all.
> > But if the same class
> > (org.apache.cassandra.io.sstable.SSTableDeletingReference) is responsible
> > for delete other files, then that's not right.
> > I checked the source code for SSTableDeletingReference, doesn't looks
> like
> > it will delete other files type.
> > Regards,
> > Chen
> >
> > On Tue, Jan 25, 2011 at 4:05 PM, Jonathan Ellis <jbel...@gmail.com>
> wrote:
> >>
> >> No, that is not expected. All the sstable components are removed in
> >> the same method; did you check the log for exceptions?
> >>
> >> On Tue, Jan 25, 2011 at 2:58 PM, Ching-Cheng Chen
> >> <cc...@evidentsoftware.com> wrote:
> >> > Using cassandra 0.7.0
> >> > The class org.apache.cassandra.io.sstable.SSTableDeletingReference
> only
> >> > remove the xxxx-Data.db file, but leave the xxx-Compacted,
> >> > xxx-Filter.db,
> >> > xxx-Index.db and xxx-Statistics.db intact.
> >> > And that's the behavior I saw. I ran manual compact then trigger a
> GC
> >> > from jconsole. The Data.db file got removed but not the others.
> >> > Is this the expected behavior?
> >> > Regards,
> >> > Chen
> >>
> >>
> >>
> >> --
> >> Jonathan Ellis
> >> Project Chair, Apache Cassandra
> >> co-founder of DataStax, the source for professional Cassandra support
> >> http://www.datastax.com
> >
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support
> http://www.datastax.com
>
