KnowledgeSessions are created from a KnowledgeBase, and they are
independent from each other, even when they come from a single
KnowledgeBase. So I don't see the need for 24 KBases.
You've referred to "fireAllRules()", which isn't available with a
StatelessKnowledgeSession. Maybe you just need a
StatelessKnowledgeSession (you're using this term in a later mail),
that, when used in *sequential mode* is faster. Otherwise, disposing a
StatelessKnowledgeSession after processing each fact may not be faster
than simply retracting the fact from a StatefulKnowledgeSession, which
would prepare it for the next task, and not cause everything to go
through GC.
Just benchmarking will tell you what is best for your scenario.
-W
On 07/02/2013, Cotton, Ben <Ben.Cotton(a)morganstanley.com> wrote:
Thanks Jeremy. Just finished watching your referenced video
"Drools &
Large Data Sets Workshop" - no doubt about it, people are explicitly using
this pattern (Pool,Queue,Delegate,Callback) w/in Drools to achieve higher
concurrent "simultaneous fact arrival" transaction throughput, and scale.
Especially appreciate your comment re: managing Runnables' callbacks w/in
the proposed framework... we indeed have to be careful here, and will
re-factor or design accordingly.
From: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Jeremy Ary
Sent: Thursday, February 07, 2013 12:08 PM
To: Rules Users List
Subject: Re: [rules-users] ambition = ThreadPoolExecutor delegating to
KBPool(s) & KSPools(s)
Yep, that all makes sense for the more elaborated context. Sounds like
you're working with a model wherein you needn't concern yourself with
relational logic between instances, so I think the value of splitting
sessions over threads with a multi-consumer queueing setup could allow you
the opportunity to async your process with better throughput. What you and I
propose differs only in high-availability and scalability of the input
stream (potentially arising from throttling to a single instance responsible
for maintaining task scheduling and executor lifecycle), offering an ability
to recover should you lose your application containing pooled tasks and
allow for smaller pool sizes to maintain (pull only as needed/desired from
queueing and adjust that capacity on the fly for high-usage times such as
first thing in the morning).
Semi-related I just found a video about a large-scale operation that
Alexandre Porcelli created that might be of some interest to you.
http://vimeo.com/27209589
My only other thoughts going into it is consider some different approaches
for the scheduling mechanism given that, as I've had the unpleasure of
discovering before, callbacks from runnables can be fun to keep up with of
you're dependent on them, so fire-and-forget vs. results synchronicity can
make a difference in the mechanism you choose to maintain your tasks and
pools.
Regards,
Jeremy
On Thu, Feb 7, 2013 at 10:47 AM, Cotton, Ben
<Ben.Cotton@morganstanley.com<mailto:Ben.Cotton@morganstanley.com>> wrote:
Thanks for your response, Ary.
It is much more about accommodating high-frequency and throughput. The
rules are ZERO sensitive to time and order - they are rendered 1x at start
of day. They are exceedingly complicated, and there are lots of them ...
but once they are bound to a KB nothing changes about them for the whole
day. When we put a fact on a KS.fireAllRules() task the rendered decision
is idempotent wrt to rules' firing(s) order.
Also, all arriving facts are immutable and all sessions are stateless, so we
kind of have ignored CEP (seeing it as more appropriate for a long-living
ecosystem of continuously mutating facts).
Effectively, we want a "small, simple, safe, speedy" body of operations on
"complex, cumbersome, concurrently-arriving, constant" facts.
From:
rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org>
[mailto:rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org>]
On Behalf Of Jeremy Ary
Sent: Thursday, February 07, 2013 11:32 AM
To: Rules Users List
Subject: Re: [rules-users] ambition = ThreadPoolExecutor delegating to
KBPool(s) & KSPools(s)
Are you in a place where your rules have become sensitive to time and order?
If so, have you considered CEP? If it's less about that and more about
getting the work done ASAP, you could also investigate a messaging
integration pattern to assist with all the pooling/throttling/queueing needs
you've mentioned.
On Thu, Feb 7, 2013 at 10:04 AM, Cotton, Ben
<Ben.Cotton@morganstanley.com<mailto:Ben.Cotton@morganstanley.com>> wrote:
Let's say that a start-of-day, every day, we generate a giant 2,000+ rule
.DRL, that we then use to construct into a single run-time KnowledgeBase
reference. We then construct a single run-time KnowledgeSession reference
(also at start of day). Throughout the day, all day, facts "arrive"
asynchronously into our expert system. When a fact "arrives", we
synchronously place the fact onto our single KS and call .fireAllRules(),
which in turn synchronously outputs answers that satisfy our "what's the
next step?" decision requirements.
We have this working very well, but we have the ambition to achieve more.
We want to attempt to scale this solution to accommodate the high-frequency
simultaneous "arrival" of many facts. We have at our disposal a 24xCPU 128
gb Linux-based compute resource (nice, right?) ... so, ideally, we have the
ambition to potentially accommodate the simultaneous arrival of 24 facts
into our expert system.
Assuming that all of our 2,000+ rules are completely isolated (i.e. no rule
i ever depends on any rule j, for all i,j) we want to consider building (at
start of day) a KSPool (size 24) , KBPool (size 24), and a
ThreadPoolExecutor (size 24, backed by BlockingQueue). As facts arrive
throughout the day, those that arrive simultaneously are Queue'd to the TPE,
that then delegates the fact's need for service to a task Runnable, which
in turn calls a KSPool[i].fireAllRules() (with isolation to KBPool[i]). In
such a scheme, we would potentially be able to render decisions concurrently
when facts arrive simultaneously ( capacity 24).
Is this design ambition common w/in current DROOLs use cases? Does the
current (or future) DROOLS offering include any in-place capability to Pool
KS or Pool KB? If not, are there any potential DROOLs concerns or "gotchas"
wrt to our pursuing this ambition (in a "let's build this now!"
prototype)?
As always, tremendous thanks to all in this community forum.
Ben D Cotton III
Morgan Stanley & Co.
OTC Derivatives Clearing Technology
1221 AOTA Rockefeller Ctr - Flr 27
New York, NY 10020
(212)762.9094<tel:%28212%29762.9094>
ben.cotton@ms.com<mailto:ben.cotton@ms.com>
________________________________
NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions
or views contained herein are not intended to be, and do not constitute,
advice within the meaning of Section 975 of the Dodd-Frank Wall Street
Reform and Consumer Protection Act. If you have received this communication
in error, please destroy all electronic and paper copies and notify the
sender immediately. Mistransmission is not intended to waive confidentiality
or privilege. Morgan Stanley reserves the right, to the extent permitted
under applicable law, to monitor electronic communications. This message is
subject to terms available at the following link:
http://www.morganstanley.com/disclaimers If you cannot access these links,
please notify us by reply message and we will send the contents to you. By
messaging with Morgan Stanley you consent to the foregoing.
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
________________________________
NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions
or views contained herein are not intended to be, and do not constitute,
advice within the meaning of Section 975 of the Dodd-Frank Wall Street
Reform and Consumer Protection Act. If you have received this communication
in error, please destroy all electronic and paper copies and notify the
sender immediately. Mistransmission is not intended to waive confidentiality
or privilege. Morgan Stanley reserves the right, to the extent permitted
under applicable law, to monitor electronic communications. This message is
subject to terms available at the following link:
http://www.morganstanley.com/disclaimers If you cannot access these links,
please notify us by reply message and we will send the contents to you. By
messaging with Morgan Stanley you consent to the foregoing.
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
________________________________
NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions
or views contained herein are not intended to be, and do not constitute,
advice within the meaning of Section 975 of the Dodd-Frank Wall Street
Reform and Consumer Protection Act. If you have received this communication
in error, please destroy all electronic and paper copies and notify the
sender immediately. Mistransmission is not intended to waive confidentiality
or privilege. Morgan Stanley reserves the right, to the extent permitted
under applicable law, to monitor electronic communications. This message is
subject to terms available at the following link:
http://www.morganstanley.com/disclaimers If you cannot access these links,
please notify us by reply message and we will send the contents to you. By
messaging with Morgan Stanley you consent to the foregoing.