Hello. I am new to Drools and have seen similar questions to mine, but I need some more detail and would love to see some insight from a Drools pro for our particular scenario :-) We are testing Drools as part of our web application backend. We want Drools to make some decisions based on a number (let's say 10) parameters we find in the incoming HttpRequest. Also, we are building a web admin interface that allows users to make changes to the Drools files that contain the business logic. We created a simple interface that allows users to create filtering rules. We store those rules in the database (field, operator, compare_against_vales, etc). Every time a user makes a change to a rule in the web admin interface (add rule, delete rule, add condition, delete condition, update condition, etc) the DRL file(s) must be regenerated and re-fed to Drools. I have a couple of questions about this: 1. How do we reload DRL files in the most efficient way? (A small code sample or a link would be great) 2. Could we create multiple small DRL files instead of one big one and would we get better performance when we only reload the (small) changed files into Drools as opposed to putting everything in one file and regenerating and reloading that? 3. Do we run the risk of Drools being "busy" with reloading DRLs while we have new Drools jobs (HttpRequests) waiting and what would happen, would we suffer a delay or do we run the risk of Drools being "unavailable"? The app is business critical. It doesn't have a super high load at the moment, but load could grow in the future and we want to plan for the worst: - a user in the web admin makes a number of changes to conditions and submits those, so we have to reload DRLs - at the exact same moment 5 incoming requests need to be evaluated by Drools 4. Can Drools manage this worst case scenario? Thanks very much for your time. -- View this message in context: http://drools.46999.n3.nabble.com/Reloading-DRL-files-from-a-web-interfac... Sent from the Drools: User forum mailing list archive at Nabble.com.