javafanboy
commented
1 year ago Can report that the work around to increase the low-units to be very close to high-units (this way ensuring that a small number of entries are evicted each time a "prune" is performed) seem to have improved the situation quite a lot (prune still seem more CPU consuming than expected though and now we instead have very frequent prunes which is not ideal either)...
Woulds appreciate info about IF that line that remove the entries from the list as they are processed is really needed (I would naively assume the whole prune operation is executed inside a "synchronized" block preventing any other operations on the local cache and in that case I do not immediately see the need to remove the elements instead of just letting them be and afterwards empty the whole array at once if it is retained or just discard it if it is temporary) and if so if you have some other suggestions of improvements to the code we can add in a "patch" for our own use... maybe use a double linked list instead of an array list that have a O(1) complexity for deleting an entry?!
mgamanho
thegridman
I am working in a project where we due to limitations of using JDK 8 and other components used are "stuck" with Coherence CE 14 and is having a challenge where evicting entries in the local cache (part of a near cache) takes a LONG time.
I realize this is not a supported release so we are looking into solving the problem ourselves but have a specific question that could help us in this...
We are profiling and seeing that the line that seem to take a lot of time is " iterEvict.remove()" in OldCache and is marked with an issue "COH-23644" that we assume introduced the line.
Not sure if this is a reference to an issue in Coherence CE or an internal Oracle issue to the enterprise edition but either way we have not been able to find any info about it and are very curious to what the issue was and why the line was introduced...
Naively when looking at the code it seems to remove keys from an ArrayList of elements to be evicted as it is iterated - it is not clear to us WHY there is a need to do this and in general removing elements from ArrayLists is expensive (at least in the past required copying the array) so we are suspecting this could be at least one reason we see slow eviction (our caches are big and so could the list of keys to evict be)....
Our first work-around that we are testing now is to increase the low-units to be about 99% of the high-units to ensure the size of the array list will be small (then the ~O(n ** 2) effect of the repeated array.remove operation is minimized) - lets see if it works...
We are also considering, as a further work around, try using Caffeine (2.X version ) as a local cache with this Coherence CE release (using the old lower level mechanism that has been available to provide your owen cache implementation) but not sure how well it would work - are experiences of this would be welcome!
I have noticed that the above mentioned line is present also in the latest Coherence CE release so if this is the cause of the problem we are seeing it may be present also with the latest...