Why return unmodifiable collections?

[Alexis]

Hey there,

I'm in the process of migrating our applications to Hector. We did quite some testing/profiling with our app, and we noticed that, while iterating over a collection of results, removing the item from the collection significantly reduces the memory pressure.

Some pseudo-code might be more meaningful here:

Iterator<Column> it = cassandra.getColumns(....).iterator();

while(it.hasNext()){

   Column c = it.next;

   it.remove();                     <----- this helps a lot

   // mess with the column....

}

I noticed that this not always possible with Hector. For instance OrderedSuperRows.getList returns an unmodifiable list, so does HSuperColumnImpl#getColumns.

I don't see why the user will be forbidden to alter the returned collections. 

I found only 4 valid occurences, so the change seems small.

        HSuperColumnImpl.java  

            (112: 23) return Collections.unmodifiableList(columns);

        OrderedRowsImpl.java  

            (40: 23) return Collections.unmodifiableList(new ArrayList<Row<K, N, V>>(rowsList));

        OrderedSuperRowsImpl.java  

            (38: 23) return Collections.unmodifiableList(rowsList);

        SuperSliceImpl.java  

            (47: 23) return Collections.unmodifiableList(columnsList);

Would you guys agree to drop this constraint?

Alexis

ps: as of today the immutability constraint is not always applied. For instance SuperRowsImpl#iterator is mutable.

[Alexis]

here is a patch:

https://github.com/rantav/hector/pull/161

[Nate McCall]

I can't recall the original reason this was added so I'd be fine with
removing this.

I've done several runs of yourkit against a stress testing application
I have and have noticed *a lot* of memory pressure around HColumn and
friends. I have several ideas to address this which I'll pontificate
on further in the next day or so.

Any other profiling results you discover, I'd be glad to know.