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:scott.g...@hotwaxsystems.com] 
Sent: Wednesday, January 20, 2016 4:33 AM
To: user@ofbiz.apache.org
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" <lsh...@solveda.com> 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
>
> lsh...@solveda.com
>
> O: 516.742.7888 x225
>
> O: 732.333.4303
>
> C: 917.882.8515
>
>

Reply via email to