[OFBiz] Users - Having a problem with findByConditionCache()

[David Vediner]

Hi Al - Thanks for the suggestion!  I had seen your earlier post and 
intended to bump up the heap.  Doing so does seem to take care of the 
cases where the soft references were being cleaned up by the GC, except 
for a few cases I'm still tracking down.

It seems to me that the other issue is unrelated, though, and is 
basically this: the method hierarchy called by the cache.get() method 
uses getConditionKey() to get the key (in ) to look up in the cache.  
The cache.put() method, however, ends up calling getFrozenConditionKey() 
to get the key (in EntityListCache.put()) when an orderBy list is used.  
getFrozenConditionKey() always returns an EntityConditionList, whereas 
getConditionKey() returns exactly the object it is passed, so unless the 
condition passed into both is an EntityConditionList, the lookup will 
always fail somewhere.  Does anyone know anything more about about this?

Thanks,
David Vediner


Al Byers wrote:

> David,
>
> I don't have much time, but here is a post of mine from a couple of 
> days ago:
>
> Ok, here is what I have learned. The reason my entity cache list was 
> not keeping entities in the cache seems to be that I was not starting 
> OFBiz with enough heap memory set. The arguments that I am using now are:
>
> VMARGS=" - Xms192M -Xmx256M -Dofbiz.admin.port=$ADMIN_PORT 
> -Dofbiz.admin.key=$ADMIN_KEY"
>
> (for starting in the debug, it looks like this:
> VMARGS=" -Xms192M -Xmx256M -Dofbiz.admin.port=$ADMIN_PORT 
> -Dofbiz.admin.key=$ADMIN_KEY -Xrs -Xdebug -Xnoagent 
> -Djava.compiler=NONE 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8999 "
> )
>
> Before I was not setting the -Xms arg at all and David said that what 
> was happening was that when the heap needed to expand it would first 
> cannibalize the caches first. So the above line in startofbiz.sh seems 
> to have fixed that.
>
> Now when I update an entity that is contained in the 
> ContentAssocDataResourceViewFrom view, it clears the "entity-list" 
> cache, but not the "entity" cache of the same name.
>
>
> _______________________________________
> Actually I fixed the first -Xms value from 192 -> 256 (probably 128 & 
> 192 would work - just so you don't start off with the minimum heap size).
>
> HTH
> -Al
>
> David Vediner wrote:
>
>> Hi -
>>
>> I have just gotten around to enabling various caches on our solution 
>> we're implementing using Ofbiz, and have run into a weird problem (or 
>> just a misunderstanding) with findByCondtionCache.  I can't seem to 
>> get it to ever successfully cache anything, not even when called from 
>> code that we haven't modified (and as near as I can tell is the same 
>> as the latest in SVN).  I have several custom caches that work fine, 
>> and the primary key caching methods seem to work fine.
>>
>> For example, I am looking at the get method called from 
>> findByCondtionCache as follows:
>> GenericDelegator.findByAndCache() -> 
>> GenericDelegator.findByConditionCache() -> Cache.get() -> 
>> EntityListCache.get() -> 
>> AbstractEntityConditionCache.getConditionCache() -> UtilCache.get()
>> I can see in that final get() method that the cache *has* the 
>> matching item stored in cache, but it's as an EntityConditionList 
>> object, and the passed in key that it looks for is an EntityFieldMap 
>> object.  So it never finds a match, and returns back through the 
>> stack as null.  The code then looks the value up in the database and 
>> puts it in the cache.  When it does, however, there's a call to 
>> .freeze() on the EntityFieldMap which recreates it as an 
>> EntityConditionList object, and so now in the put() method the cache 
>> item is found.  However, when it does so it expires it because the 
>> .getValue() on the item is null (I don't know why) and 
>> useSoftReferences is true.  I don't know if this expiration is 
>> related to not being able to get the item, but like I said, in the 
>> cache fetch code the item is always there - it just seems to be a 
>> different type of object then is being looked up.  I think I can fix 
>> it by just making sure all the keys passed in are wrapped in an 
>> EntityConditionList object, but I don't want to do that if this isn't 
>> really a bug and I'm just not getting something.  Plus I have no idea 
>> why the items are being expired (or if that's even related).
>>
>> I *believe* that all the code that this interfaces with is up to date 
>> with the latest from SVN.  I also know that the cache stuff changed 
>> recently, and that I could just be confused about how this whole 
>> thing works, but there's enough unknowns in there about how it's 
>> supposed to work that I can't quite figure it out.  Is 
>> findByConditionCache even still in use?
>>
>> Thanks!
>>
>> David Vediner
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ofbiz.org
>> http://lists.ofbiz.org/mailman/listinfo/users
>>
>
>