[rules-users] Caching of JBoss Rules bytecode field readers

[Mark Proctor]

The getters are generated by this class:
http://fisheye.jboss.org/browse/JBossRules/branches/4.0.x/drools-core/src/main/java/org/drools/base/ClassFieldExtractorFactory.java?r=15671
It creates a ClassLoader using the RuleBase classloader as the parent.

The generated classes are also stored in the cache:
http://fisheye.jboss.org/browse/JBossRules/branches/4.0.x/drools-core/src/main/java/org/drools/base/ClassFieldExtractorCache.java?r=15671

However this cache is a singleton so I guess if you have two rulebases 
which reference different threads and then you execute on another thread 
- the cache is on the executing thread, the code generation on the 
referenced threads.

mark
Keith Bennett wrote:
> Thanks for the explanation, Mark.  Sorry if it appeared that the focus
> of my poorly worded question was why Strings were used for the key.
> Using Strings makes total sense to me.  I was really just trying to
> better understand how caching is implemented to help me better
> understand why I'm having the problem I originally posted about.
>
> Can you explain to me how, through the JBoss Rules API, I can always
> ensure that I'm not picking anything up from an internal cache when I
> deploy new rules?  I want to always make sure that the rules from the
> new drl file I place in the classpath are always picked up, not
> anything that was previously cached internally by JBoss Rules.
> Thanks.
>
> Keith
>
> On Wed, Jul 9, 2008 at 9:15 AM, Mark Proctor <mproctor at codehaus.org> wrote:
>   
>> We generate bytecode readers for performance, it would be possible to plugin
>> a reflection based reader that would avoid this issue, but we don't have
>> plans to this due to time - we would accept a patch. With regards to why the
>> String for the key, why not? What other key would you imagine we should
>> keep? I guess we could alos look into a classloader specific var to hold the
>> cache.
>>
>> Shows the classes we use to generate field accessors.
>> http://fisheye.jboss.org/browse/JBossRules/tags/4.0.7.19894.GA/drools-core/src/main/java/org/drools/util/asm
>>
>> If you do an import of the project into eclipse you can see where those
>> classes are used from and maybe come up with a solution - please make sure
>> there are no performance loses.
>>
>> Mark
>> Keith Bennett wrote:
>>     
>>> I found a link that might explain what is happening with the problem I
>>> described in another posting (included below):
>>> http://jira.jboss.com/jira/browse/JBRULES-1009
>>>
>>> Mark Proctor, if you read this posting, can you please explain in more
>>> detail how and why JBoss Rules generates bytecode field readers and
>>> caches them by string name?  I would appreciate it.  Could this
>>> explain the issue I'm experiencing as described below?
>>>
>>> I have scoured the documentation and have tried many different
>>> approaches to solving this problem, to no avail.  I absolutely can not
>>> get the new version of a .drl file to load with just an application
>>> restart in Tomcat.  I have to restart Tomcat each time.  In my mind,
>>> this has to be a classloader issue.  I just don't know how to get
>>> around it.  I would really appreciate any help!
>>>
>>> Keith
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Keith Bennett <forthwind at gmail.com>
>>> Date: Wed, Jul 2, 2008 at 9:47 AM
>>> Subject: New rules in source file not loaded when application redeployed
>>> To: Rules Users List <rules-users at lists.jboss.org>
>>>
>>>
>>> I am packaging my rules as a drl source file in a jar that is then
>>> bundled in a war file that is then deployed to Tomcat. In my
>>> implementation, the rulebase is cached the first time it is used in my
>>> application, but when I add new rules to the source file and rebuild
>>> my application then redeploy it on Tomcat, the new version of the
>>> rules don't get loaded into the rulebase.
>>>
>>> Why and how is an older version of the rules being loaded into the
>>> rulebase when I redeploy my application in Tomcat?  As FYI, I have
>>> developed a business rules service that initializes the rulebase upon
>>> a Spring container startup by loading the drl file from the classpath.
>>>  Is there an internal Drools static cache that is scoped to something
>>> other than my application?  The only thing I can do to load the new
>>> rules is restart Tomcat.  When I do this, the new version of the drl
>>> source file is loaded and used, so I'm thinking the problem I'm having
>>> is somehow related to the class loaders Tomcat uses, but I can't find
>>> information about what Drools might be doing internally with a static
>>> cache or something like that.
>>>
>>> Can anyone explain what might be happening and how to configure Drools
>>> and/or my application to get around this problem I'm having?  I
>>> definitely appreciate any help you can provide!
>>>
>>> Keith
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>>       
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>     
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20080710/f9fcb59e/attachment.html