Loading a stateless knowledge session with ~10k facts and the one (or few) transaction fact(s) for a single transaction isn't economic.
I'd benchmark the costs for inserting the transaction fact(s) into a statefeul session, run fireAllRules(), returning the result and removing the debris in a thread. This should give you a good indication how many of these you can do per second, and the potential delay for concurrent requests when transactions are done in turn. -W On 02/05/2012, [email protected] <[email protected]> wrote: > I would suggest making your service stateless and run the service in > multiple JVMs to alleviate performance concerns. You will be able to scale > and also not have to worry about cramming everything into a > StatefulKnowledgeSession and worry abt thead-safety. > > > > From: Stephen Lomax <[email protected]> > To: Rules Users List <[email protected]>, > Date: 05/02/2012 04:28 AM > Subject: Re: [rules-users] Query for a fact, and concurrent rule > execution > Sent by: [email protected] > > > > Hi Mike, > > Many thanks for that..we had previously thought of serialising to file but > thought the purpose of the StatefulKnowledgeSession was to keep it live in > memory continuously, rather than instantiating a new session with each web > service call. > > > My concern is that if we instantiate a new session with each web service > call the memory required will increase massively (if we have many > concurrent requests). Is there a way of serving multiple concurrent > requests against the same session to remove that concern. > > Many thanks for your help with this..it is very much appreciated. > > Ste > > > . > On 2 May 2012, at 12:08, Michael Anstis wrote: > > That's a possibility, but it'd depend on your rules. > > As a thought, you could serialise the initialised > StatelessKnowledgeSession into a byte[] (cached at application scope) and > deserialise with each web-service call. > > I would wait to see if Mark Proctor, Edson Tirelli or community members > have other thoughts on use of a single StatefulKnowledgeSession. > > IIRC it is meant to be thread-safe but think people have reported problems > in the past. Recently: > http://lists.jboss.org/pipermail/rules-dev/2012-February/003857.html > > With kind regards, > > Mike > > On 2 May 2012 11:58, Stephen Lomax <[email protected]> wrote: > Hi Mike, > > Each quote does not enrich the session, we were actively looking to remove > the quote at the end of the session to prevent it growing as we were just > comparing the quote to the core product attribute facts. > > What is the performance hit in launching a Stateful knowledge session with > say 10,000 facts, would it make the web service call slow? > > Thanks very much for the help on the query also…we will look into that. > > Kind Regards > > Ste > > On 2 May 2012, at 11:31, Michael Anstis wrote: > > Does each quote validation exercise enrich the StatefulKnowledgeSession > with other facts that could influence validation of other quotes? > > If not probably using a StatefulKnowledgeSession per HTTP request might be > more simple (with the KnowledgeBase as an application scoped variable). > > Regarding retrieval of results, there are a couple of options that spring > to mind:- > Look at using a Global to collate results. > Look at using a Query ( > http://stackoverflow.com/questions/5872215/how-do-i-add-facts-to-working-memory-at-runtime-in-the-drools-drl-and-retrieve-t > ) > With kind regards, > > Mike > > On 2 May 2012 10:39, stelomax <[email protected]> wrote: > Hi, > > Please bear with me, I am relatively new to the world of Drools and have a > question. I am hoping it will be a simple issue. > > First let me frame my planned implementation at a high level. I am hoping > to use Drools as a real time service enabled quote validation tool. > > Facts representing products and attributes will be loaded into a stateful > knowledge session upon boot (using a piece of Java that loads these as > facts > from our product DB). > > The front-end application will allow users to build up quotes consisting > of > quote lines that make references to these products. Once the quote is > built > they will press a "Validate" button. This will call a webservice that > will: > > 1) Insert the quote details as facts into the knowledge session > 2) Run a "rule flow" to validate the quote against the product facts > 3) The rules will insert validation results as facts tagged against the > quote > 4) QUERY for the validation results > 5) Retract the facts for the quote (inc validation results) > 6) Send the validation results back as a response to the webservice call > > My first question is how to implement step 4 --> how to physically query > for > the validation results pertaining to that specific quote. Any help here > would be greatly appreciated. > > My second question relates to concurrency. As this is a quote validation > tool there will be multiple users validating quotes so we will get > concurrent validation requests. > > What is the recommended manner of dealing with concurrent rule requests > within a stateful knowledge session. If 2 people attempt to validate a > different quote at the same time we will have two quotes within the > knowledge session together with all of the product facts. Is drools > capable > of running two concurrent rule flows against the knowledge session, each > referencing a different quote or would we need to instantiate 2 knowledge > sessions, or even deal with the matter in a serial manner placing the 2nd > quote validation flow on hold until the first completes? > > Any help/pointers would be great. I am hoping someone out there has > attempted to use Drools in a similar manner :) > > Many Thanks > > Ste > > -- > View this message in context: > http://drools.46999.n3.nabble.com/Query-for-a-fact-and-concurrent-rule-execution-tp3954737.html > > Sent from the Drools: User forum mailing list archive at Nabble.com. > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > > > > ----------------------------------------- > The information contained in this communication (including any > attachments hereto) is confidential and is intended solely for the > personal and confidential use of the individual or entity to whom > it is addressed. If the reader of this message is not the intended > recipient or an agent responsible for delivering it to the intended > recipient, you are hereby notified that you have received this > communication in error and that any review, dissemination, copying, > or unauthorized use of this information, or the taking of any > action in reliance on the contents of this information is strictly > prohibited. If you have received this communication in error, > please notify us immediately by e-mail, and delete the original > message. Thank you _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
