[infinispan-dev] SimpleFileCacheStore

[Radim Vansa]

On 07/30/2013 07:18 PM, Mircea Markus wrote:
> Adding infinispan dev and Martin.
> I think it makes a lot of sense for QE to run the tests you suggested.
>
> Sent from my iPhone
>
> On 30 Jul 2013, at 17:56, Shane Johnson <shjohnso at redhat.com> wrote:
>
>> I was looking at the code for this cache store the other day.
>>
>> I noticed that is neither a log structured nor a b/b+ tree implementation and it lacks compaction. Maybe it is elsewhere or I simply missed it?

No, the storage does not need any search structure as it keeps all keys 
with entry position in-memory, what is its major drawback.

>> Have we run a long test (as in hours) with variable length values? It looks like this implementation may be inefficient in that it would result in numerous gaps (unusable free entries) if the values grow or shrink in size.
No, we have not run such tests. Regarding the gaps - the implementation 
always uses smallest fitting allocated block, if such block does not 
exist, it allocates another on the end of file. It does not coalesce 
neighbour free blocks but neither splits them.
In worst-case scenario with growing size of the entries used, yes, it 
would leave old free blocks unused. But if the distribution of entry 
size does not change this is not a problem in my opinion.
>> Where the tests run on SSD drives? I'd think that this type of random read/write would not be terribly efficient on an HDD.
Currently, QE doesn't have any HW with SSD drives.
>> Have we done performance testing using FileDescriptor.sync() and have we considered using an AsynchronousFileChannel instead?
Not sure what are you asking for - file syncing in tests was achieved by 
calling FileChannel.force(false). You won't find the code for that, I've 
just hacked it locally.

Radim