It does cause issues since it seems the original cache (without the 1) does not properly clear.
In my situation it happens to be the DataResource cache.
As you know Content is stored in the three cache stores Content, DataResource, Electronic Text.
We are in a clustered environment using ActiveMQ to distribute the cache clear.
In our case on the second instance the DataResource cache was in conflict and therefore named DataResoure1.
When the first instance updated its cache store the DataResource cache on the second instance never gets cleared. I believe due to the fact it seemingly is not there by the same name, on the second instances' cache store list.
The odd thing when viewing the list of cache stores via webtools. We see the cache store with the 1 appended, and it shows the 'stats' of this cache. However when clicking on the any of the 'detail' links we get cache store not found. Removing the '1' from the URl parameter line does then properly show the detail of the 'original' cache. If the cache store is subsequently 'cleared'; of course it then shows the correct data on ecommerce site.
The method is UtilCache.getOrCreateUtilCache; if the cache determines the file to be 'unsafe' it executes compareAndSwapInt. What I am puzzled at is what is the conflict or unsafe which causes the next atomic number to be generated?
Regards
Len
-----Original Message-----
From: Scott Gray [mailto:
[hidden email]]
Sent: Wednesday, January 20, 2016 4:33 AM
To:
[hidden email]
Subject: Re: An index number appended to utilCacheTable names when there are conflicts?
It's most likely a race condition in the UtilCache getOrCreate method (the exact name escapes me without looking). Does it a actually cause any issues or is it just strange?
On 20 Jan 2016 11:41, "Len Shein" <
[hidden email]> wrote:
> All,
>
> There have been instances where one or more of the entitycache store
> gets an index number appended to it's name.
>
> The UtilCache.java file has the following notation:
>
>
>
> /** An index number appended to utilCacheTable names when there
> are conflicts. */
>
> private final static ConcurrentHashMap<String, AtomicInteger>
> defaultIndices = new ConcurrentHashMap<String, AtomicInteger>();
>
>
>
> Does anyone know what kind of conflict would cause a cache store to
> get such an index number?
>
> Also the original named cache is no longer present in the cache store list?
>
>
>
> For example:
>
> entitycache.entity.default.ProdCatalog1
>
> And the original is gone.
>
> entitycache.entity.default.ProdCatalog
>
>
>
> Note: This is occurring in a clustered environment which we are using
> ActiveMQ to distribute our cache clearing.
>
>
>
> Len Shein
>
>
[hidden email]
>
> O: 516.742.7888 x225
>
> O: 732.333.4303
>
> C: 917.882.8515
>
>
Locked
