How to use Caffeine as Front cache

[lyiu18]

Does anyone try to use Caffeine as front cache in near cache scheme?
The instruction in link below, does not seem to work, the XSD validation won't pass
https://docs.oracle.com/en/middleware/standalone/coherence/14.1.1.2206/develop-applications/implementing-storage-and-backing-maps.html#GUID-BB75B2EB-5FCF-41D6-919E-013DCBCC39C0

caffeine-near-scheme





my-dist-scheme

Did I miss something? or there are some work-around I can try?

Thanks

[jfialli]

The schema coherence-cache-config.xsd is currently incorrect in 14.1.1.2206 coherence-cache-config.xsd to allow for caffeine-scheme. Updated front-scheme with a workaround for you.

<xsd:element name="front-scheme">
        <xsd:annotation>
            <xsd:documentation> 
                The front-scheme element contains the front tier
                cache configuration info.
                
                Used in: overflow-scheme, near-scheme
            </xsd:documentation>
        </xsd:annotation>
        <xsd:complexType>
            <xsd:sequence>
                <xsd:choice>
                    <xsd:element ref="local-scheme" />
                    <xsd:element ref="class-scheme" />
                    <!-- you can add the next line to workaround issue until we address it in next patch -->
                    <xsd:element ref="caffeine-scheme" />
                </xsd:choice>
                <xsd:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded" />
            </xsd:sequence>
            <xsd:anyAttribute namespace="##other" processContents="lax" />
        </xsd:complexType>
    </xsd:element>

I am filing a bug to get this issue addressed.

[lyiu18]

Appreciated, that works

A related question about Caffeine

I also tried to use Caffeine as backing map, not exactly like the document shown, since I need to use cachestore, I kept read-write-backing-map-scheme and internal-cache-scheme, then replaced local-scheme with caffeine-scheme under it, it can work this way, and i can see the Caffeine map get created. my question is:

1. if I use this way, do I still get benefit of using Caffeine as backing map?
2. when i try this way, one of my test case failed, the test case uses AsyncMap.putAll to insert values into this map on one thread, and calling map.clear on the other thread. the clear method will end up in com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.partitionedCache.Storage.clear
   the clear method try to remove each of the item, however, it seems some of the items was not there in the internal Caffeine map yet. I didn't see this problem when just use localmap. Not really sure where it goes wrong, why it seems the storage know there is a key, but internal Caffeine does not have the key.
   Not sure if there is enough info for you to replicate the problem, please help me check.

[jfialli]

Your follow up question is quite different than the original question. So it should be in a different question or issue.

Given the complexity of the description and the numerous features described, we do need more than a casual list of the features used.
Could you file an issue and attach files to help to describe the circumstances more definitively. A recreation of the issue would be best.

Minimally, we need to see the coherence cache configuration, the CacheStore implementation and the application code that
is performing AsyncNamedCache#putAll and calling the clear.

Additionally, it is quite non-deterministic to state you are performing an AsyncNamedCache.putAll in one thread and calling clear() on another thread. Are you certain the putAll has completed by waiting on the completablefuture returned by AsyncNamedCache.putAll() ?

[lyiu18]

Thanks I will try to put together info to open an issue later

Are you certain the putAll has completed by waiting on the completablefuture returned by AsyncNamedCache.putAll()

That is my point, I am not sure if the put is completed, And most likely it is not, however, that should not give us an uncertain status of the cache, while up-level (assume it is in readwritebackingmap or storage) has the key, the lower-level (internal Caffeine cache) does not have it. This does not happen for normal LocalCache implementation, and I don't think I have too many entries causing eviction yet