Wolfgang Laun | 3 Mar 11:23 2012
Picon

Re: Streaming mode

I think that Drools doesn't use any threads except for timers and for the Knowledge Agent. So you should check where these other threads come from. Code in ExpertVS.java appears to be running in several threads?


To learn more about fact retractions: attach a WM event listener and log the org.drools.runtim.rule.PropagationContext.

-W


2012/3/2 Matteo Cusmai <cusmaimatteo <at> gmail.com>
Hi Wolfgang,
i think that have to study more in deed some manuals, because there are some aspects not very clear, in particular the threads behavior.
For example, i have a class running in a container (thread A) that launch the session as follow:
......
        ksession = kbase.newStatefulKnowledgeSession();
......
        Thread t = new Thread(new Runnable() { public void run() { ksession.fireUntilHalt();}});
        t.setName("ExpertSystem");
        t.start();

the same thread A insert event into a stream:
.....
        entryPoint = ksession.getWorkingMemoryEntryPoint(entryPointName);
.....
        entryPoint.insert(obs);

i have a rule some rules such as these:

rule "gas1-event"
    salience 10
    no-loop
    when
        $obs    : GasObservation( $obsLocation : location, gasname == "UN 1017", value > 60 ) over window:length(1) from entry-point lowLevelSensorStream
        not GasEvent( gasname == "UN 1017", this meets[50s] $obs, location geoIntersects $obsLocation )
    then
        insert(new GasEvent( $obs, "UN 1017 value > threshold[60]", Event.THREAT_HIGH, $obsLocation, $obs.getSensor()));
end
rule "gas1-event-update"
    salience 5
    no-loop
    when
        $obs    : GasObservation( $obsLocation : location, gasname == "UN 1017", value > 60 ) over window:length(1) from entry-point lowLevelSensorStream
        $event     : GasEvent( gasname == "UN 1017", this meets[50s] $obs, location geoIntersects $obsLocation )
    then
        Event e = Event.clone($event);
        insert( e );
        retract($event);
        retract($obs);
end

i see that there are some other threads that insert new event and some others retract them.
How is the thread model?

Thanks a lot,
Matteo.

2012/3/2 Wolfgang Laun <wolfgang.laun <at> gmail.com>
What's the declare for the Event type? What does rule gas2-event do?
-W


2012/3/2 Matteo Cusmai <cusmaimatteo <at> gmail.com>
Hi all,
i have a big problem with drools fusion.

I insert some new event (pojo object) into Working Memory, but another thread retract it after a few ms.

Someone could tell me why?

Thanks a lot,



[java] gas2-event: 1330701201208
     [java] INFO  [2012-03-02 16:13:21,261] [ExpertSystem] (ExpertVS.java:141)     - **** eventRetracted: 1330701201232/30/32/0/100
     [java] INFO  [2012-03-02 16:13:31,224] [Thread-19] (ExpertVS.java:135)     - objectInserted org.dfms.model.observation.GasObservation <at> 1a30ef85
     [java] INFO  [2012-03-02 16:13:31,225] [Thread-19] (ExpertVS.java:135)     - objectInserted org.dfms.model.observation.GasObservation <at> 2bd1232
     [java] INFO  [2012-03-02 16:13:31,226] [Thread-19] (ExpertVS.java:135)     - objectInserted org.dfms.model.observation.GasObservation <at> 4045acb5
     [java] INFO  [2012-03-02 16:13:31,227] [Thread-19] (ExpertVS.java:135)     - objectInserted org.dfms.model.observation.TemperatureObservation <at> 1e4dc00a
     [java] INFO  [2012-03-02 16:13:31,227] [Thread-19] (ExpertVS.java:135)     - objectInserted org.dfms.model.observation.HumidityObservation <at> 27ae011
     [java] INFO  [2012-03-02 16:13:31,227] [pool-1-thread-1] (ExpertVS.java:124)     - **** eventInserted: 1330701211226/30/32/0/100
     [java] INFO  [2012-03-02 16:13:31,240] [Thread-19] (ExpertVS.java:135)     - objectInserted org.dfms.model.observation.RadiationObservation <at> 510c7d5c
     [java] INFO  [2012-03-02 16:13:31,251] [pool-1-thread-1] (ExpertVS.java:143)     - objectRetracted ==>[ObjectRetractedEventImpl: getFactHandle()=1:105:45945394:45945394:105:lowLevelSensorStream, getOldObject()=org.dfms.model.observation.GasObservation <at> 2bd1232, getKnowledgeRuntime()=org.drools.impl.StatefulKnowledgeSessionImpl <at> 7224e11c, getPropagationContext()=PropagationContextImpl [activeActivations=0, dormantActivations=0, entryPoint=EntryPoint::lowLevelSensorStream, factHandle=1:105:45945394:45945394:105:lowLevelSensorStream, leftTuple=1:105:45945394:45945394:105:lowLevelSensorStream
     [java] [fact 0:0:124232201:1306428912:0:DEFAULT:org.drools.reteoo.InitialFactImpl <at> 4dde85f0]
     [java] , originOffset=-1, propagationNumber=220, rule=[Rule name=gas2-event, agendaGroup=MAIN, salience=10, no-loop=true], type=1]]
     [java] gas2-event: 1330701211203
     [java] INFO  [2012-03-02 16:13:31,261] [ExpertSystem] (ExpertVS.java:141)     - **** eventRetracted: 1330701211226/30/32/0/100
     [java] INFO  [2012-03-02 16:13:31,262] [ExpertSystem] (ExpertVS.java:143)     - objectRetracted ==>[ObjectRetractedEventImpl: getFactHandle()=1:101:1512664237:1512664237:101:lowLevelSensorStream, getOldObject()=org.dfms.model.observation.TemperatureObservation <at> 5a296cad, getKnowledgeRuntime()=org.drools.impl.StatefulKnowledgeSessionImpl <at> 7224e11c, getPropagationContext()=PropagationContextImpl [activeActivations=0, dormantActivations=0, entryPoint=EntryPoint::lowLevelSensorStream, factHandle=1:101:1512664237:1512664237:101:lowLevelSensorStream, leftTuple=null, originOffset=-1, propagationNumber=224, rule=null, type=1]]
     [java] INFO  [2012-03-02 16:13:31,262] [ExpertSystem] (ExpertVS.java:143)     - objectRetracted ==>[ObjectRetractedEventImpl: getFactHandle()=1:102:1436418073:1436418073:102:lowLevelSensorStream, getOldObject()=org.dfms.model.observation.HumidityObservation <at> 559e0019, getKnowledgeRuntime()=org.drools.impl.StatefulKnowledgeSessionImpl <at> 7224e11c, getPropagationContext()=PropagationContextImpl [activeActivations=0, dormantActivations=0, entryPoint=EntryPoint::lowLevelSensorStream, factHandle=1:102:1436418073:1436418073:102:lowLevelSensorStream, leftTuple=null, originOffset=-1, propagationNumber=226, rule=null, type=1]]
     [java] INFO  [2012-03-02 16:13:31,263] [ExpertSystem] (ExpertVS.java:143)     - objectRetracted ==>[ObjectRetractedEventImpl: getFactHandle()=1:103:2014876984:2014876984:103:lowLevelSensorStream, getOldObject()=org.dfms.model.observation.RadiationObservation <at> 78189538, getKnowledgeRuntime()=org.drools.impl.StatefulKnowledgeSessionImpl <at> 7224e11c, getPropagationContext()=PropagationContextImpl [activeActivations=0, dormantActivations=0, entryPoint=EntryPoint::lowLevelSensorStream, factHandle=1:103:2014876984:2014876984:103:lowLevelSensorStream, leftTuple=null, originOffset=-1, propagationNumber=228, rule=null, type=1]]
     [java] INFO  [2012-03-02 16:13:41,228] [ExpertSystem] (ExpertVS.java:143)     - objectRetracted ==>[ObjectRetractedEventImpl: getFactHandle()=1:108:508411914:508411914:108:lowLevelSensorStream, getOldObject()=org.dfms.model.observation.TemperatureObservation <at> 1e4dc00a, getKnowledgeRuntime()=org.drools.impl.StatefulKnowledgeSessionImpl <at> 7224e11c, getPropagationContext()=PropagationContextImpl [activeActivations=0, dormantActivations=0, entryPoint=EntryPoint::lowLevelSensorStream, factHandle=1:108:508411914:508411914:108:lowLevelSensorStream, leftTuple=null, originOffset=-1, propagationNumber=230, rule=null, type=1]]
     [java] INFO  [2012-03-02 16:13:41,230] [ExpertSystem] (ExpertVS.java:143)     - objectRetracted ==>[ObjectRetractedEventImpl: getFactHandle()=1:109:41607185:41607185:109:lowLevelSensorStream, getOldObject()=org.dfms.model.observation.HumidityObservation <at> 27ae011, getKnowledgeRuntime()=org.drools.impl.StatefulKnowledgeSessionImpl <at> 7224e11c, getPropagationContext()=PropagationContextImpl [activeActivations=0, dormantActivations=0, entryPoint=EntryPoint::lowLevelSensorStream, factHandle=1:109:41607185:41607185:109:lowLevelSensorStream, leftTuple=null, originOffset=-1, propagationNumber=232, rule=null, type=1]]


_______________________________________________
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


_______________________________________________
rules-users mailing list
rules-users <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Mark Proctor | 3 Mar 11:50 2012

Re: Drools 5.3 partitioned rule base

On 02/03/2012 18:14, gboro54 wrote:
> How does MultithreadEvaluationOption work on a kBase? It is not explained
> really clearly anywhere. I know if I insert single objects only this works
> but as soon as two more of an object goes in I begin getting NPE...
The feature is experimental and currently has problems, it's not 
recommended you use it.

Mark
>
>
> Mark Proctor wrote
>> Drools doesn't partition. You will need to build an external framework
>> that partitions your data, and then assign a ksession per parition.
>> Whether it's a ksession or kbase per partition depends on whether you
>> can use the same rules per partition or not.
>>
>> Mark
>> On 02/03/2012 17:33, gboro54 wrote:
>>> Could someone explain a little more about how Drools does a partition. I
>>> believe I understand Mark's idea, I just need to flush it out some more
>>>
>>> --
>>> View this message in context:
>>> http://drools.46999.n3.nabble.com/Drools-5-3-partitioned-rule-base-tp3793558p3794163.html
>>> Sent from the Drools: User forum mailing list archive at Nabble.com.
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users <at> .jboss
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>> _______________________________________________
>> rules-users mailing list
>> rules-users <at> .jboss
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
> --
> View this message in context: http://drools.46999.n3.nabble.com/Drools-5-3-partitioned-rule-base-tp3793558p3794296.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> 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

Mark Proctor | 3 Mar 11:51 2012

Re: Drools 5.3 partitioned rule base

On 02/03/2012 17:52, gboro54 wrote:
> Would you partition the KnowledgeBase or the Sessions? Additional would each
> Order being evaluated create a new session?
It depends on your problem and your data.

Mark
>
>
>
> gboro54 wrote
>> Could you elaborate on that a little more Mark?
>>
>>
>> Mark Proctor wrote
>>> Parition yourself ahead of time. Choose a key that is a true partition
>>> of your data, chose the number of partitions, create a kbase per
>>> partition and then hash on your inserted data to get the target kbase.
>>>
>>> Mark
>>> On 02/03/2012 16:23, gboro54 wrote:
>>>> We are writing a billing system using Drools to evaluate orders placed
>>>> during
>>>> the day(this is a month to date process which will run nightly and we
>>>> will
>>>> be bringing a real-time solution online later this year after we rewrite
>>>> the
>>>> existing). Base fees of these orders can happen in parallel and in no
>>>> way
>>>> affect one another, however we have price caps which do depend on the
>>>> order
>>>> in which the cap is applied to the order(for certain conditions on an
>>>> order
>>>> a surcharge may be created if a cap is applied). My past experience will
>>>> Drools has been it is quicker to do as much evaluation up front rather
>>>> then
>>>> loop of a list of Orders and fire one at a time. However my experience
>>>> in
>>>> running Drools with this load is limited(by the end of the month we will
>>>> have to process 15 million orders).  I am open to suggestions on the
>>>> best
>>>> way to do this. Additionally orders are reprocessed each night as orders
>>>> from a current day may affect the pricing of an order from previous
>>>> days(i.e
>>>> a tier rate may apply, etc.)
>>>>
>>>>
>>>> On a side note I found that the issue is a NPE exception one of my rules
>>>> which only occurs if I partition the rule base(I am not sure why this
>>>> would
>>>> make a difference).
>>>>
>>>> --
>>>> View this message in context:
>>>> http://drools.46999.n3.nabble.com/Drools-5-3-partitioned-rule-base-tp3793558p3793979.html
>>>> Sent from the Drools: User forum mailing list archive at Nabble.com.
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> rules-users <at> .jboss
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users <at> .jboss
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>
> --
> View this message in context: http://drools.46999.n3.nabble.com/Drools-5-3-partitioned-rule-base-tp3793558p3794233.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> 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

gboro54 | 3 Mar 14:11 2012
Picon

Re: Drools 5.3 partitioned rule base

Mark,

 I really appreciate the help and think I have come to a solution. Let me
know if this sounds reasonable.
1. We will continue to use jBPM to coordinate the rules and business logic
that need to occur in calculating charges for orders. However we will work
the process to only work on a per order level.
2. All orders are associated with accounts. We will keep one knowledgebase
as the rule sets are the same and we will partition sessions by accounts.
The flow will go as follows:
a. If the session exists insert the order, start a new process instance and
fire all rules
b. If the session has not been created: create the session, insert all
reference data that will be used by all orders in executions of the rule
set, insert the order, start a process, and fire all rules. This session is
then cached(via a hashmap more then likely)
c. This process will be invoked asyn from the main thread, allowing us to
control the multithreading 
3. Orders will be treated as an event and will be set to expire in a certain
amount of time, allowing us to mange the memory footprint of each session. 

Does this sound reasonable based on what you know of our usecase?
Additionally with expiring Orders does this cause a reevaluation of the
rules when the expiration occurs? The only other question I have is does the
expiration clock start when no more activation's get created for the given
event?

Thanks again.

--
View this message in context: http://drools.46999.n3.nabble.com/Drools-5-3-partitioned-rule-base-tp3793558p3795920.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

Wolfgang Laun | 3 Mar 20:35 2012
Picon

Re: Drools 5.3 partitioned rule base

Starting a new thread (if that's what you mean by process) for reusing

an existing session to process another order is likely to create more overhead
and it'll just make threads compete for this resources.

Multiple threads each dedicated to a single session object might be a
better way to go.

I don't see any benefit to make simple order facts into events just for the sake
of making them expire automatically. There ought to be a well defined
state (or states) when processed orders are retracted by some rule.

-W


On 3 March 2012 14:11, gboro54 <gboro54 <at> gmail.com> wrote:
Mark,

 I really appreciate the help and think I have come to a solution. Let me
know if this sounds reasonable.
1. We will continue to use jBPM to coordinate the rules and business logic
that need to occur in calculating charges for orders. However we will work
the process to only work on a per order level.
2. All orders are associated with accounts. We will keep one knowledgebase
as the rule sets are the same and we will partition sessions by accounts.
The flow will go as follows:
a. If the session exists insert the order, start a new process instance and
fire all rules
b. If the session has not been created: create the session, insert all
reference data that will be used by all orders in executions of the rule
set, insert the order, start a process, and fire all rules. This session is
then cached(via a hashmap more then likely)
c. This process will be invoked asyn from the main thread, allowing us to
control the multithreading
3. Orders will be treated as an event and will be set to expire in a certain
amount of time, allowing us to mange the memory footprint of each session.

Does this sound reasonable based on what you know of our usecase?
Additionally with expiring Orders does this cause a reevaluation of the
rules when the expiration occurs? The only other question I have is does the
expiration clock start when no more activation's get created for the given
event?

Thanks again.

--
View this message in context: http://drools.46999.n3.nabble.com/Drools-5-3-partitioned-rule-base-tp3793558p3795920.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
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
gboro54 | 3 Mar 20:45 2012
Picon

Re: Drools 5.3 partitioned rule base

Agreed that I can have a rule to retract the order....i was just thinking if
the overhead of a reevaluation but can live with that...As far as the
threading...this logic is going to be deployed on a jboss instance using ejb
so I was thinking about, using the jboss thread pool...so when I say new
thread it may not, be new put, pulled from a pool....does that sound
reasonable?

laune wrote
> 
> Starting a new thread (if that's what you mean by process) for reusing
> an existing session to process another order is likely to create more
> overhead
> and it'll just make threads compete for this resources.
> 
> Multiple threads each dedicated to a single session object might be a
> better way to go.
> 
> I don't see any benefit to make simple order facts into events just for
> the
> sake
> of making them expire automatically. There ought to be a well defined
> state (or states) when processed orders are retracted by some rule.
> 
> -W
> 
> 
> On 3 March 2012 14:11, gboro54 &lt;gboro54 <at> &gt; wrote:
> 
>> Mark,
>>
>>  I really appreciate the help and think I have come to a solution. Let me
>> know if this sounds reasonable.
>> 1. We will continue to use jBPM to coordinate the rules and business
>> logic
>> that need to occur in calculating charges for orders. However we will
>> work
>> the process to only work on a per order level.
>> 2. All orders are associated with accounts. We will keep one
>> knowledgebase
>> as the rule sets are the same and we will partition sessions by accounts.
>> The flow will go as follows:
>> a. If the session exists insert the order, start a new process instance
>> and
>> fire all rules
>> b. If the session has not been created: create the session, insert all
>> reference data that will be used by all orders in executions of the rule
>> set, insert the order, start a process, and fire all rules. This session
>> is
>> then cached(via a hashmap more then likely)
>> c. This process will be invoked asyn from the main thread, allowing us to
>> control the multithreading
>> 3. Orders will be treated as an event and will be set to expire in a
>> certain
>> amount of time, allowing us to mange the memory footprint of each
>> session.
>>
>> Does this sound reasonable based on what you know of our usecase?
>> Additionally with expiring Orders does this cause a reevaluation of the
>> rules when the expiration occurs? The only other question I have is does
>> the
>> expiration clock start when no more activation's get created for the
>> given
>> event?
>>
>> Thanks again.
>>
>> --
>> View this message in context:
>> http://drools.46999.n3.nabble.com/Drools-5-3-partitioned-rule-base-tp3793558p3795920.html
>> Sent from the Drools: User forum mailing list archive at Nabble.com.
>> _______________________________________________
>> rules-users mailing list
>> rules-users <at> .jboss
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
> 
> _______________________________________________
> rules-users mailing list
> rules-users <at> .jboss
> https://lists.jboss.org/mailman/listinfo/rules-users
> 

--
View this message in context: http://drools.46999.n3.nabble.com/Drools-5-3-partitioned-rule-base-tp3793558p3796613.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

gboro54 | 3 Mar 21:30 2012
Picon

Re: Drools 5.3 partitioned rule base

My previous statement was poorly written(that is what I get for trying to
respond via my cell phone ). I agree that the Order fact is simple enough to
have a rule retract it once processing is completed. As far as the
threading, this is an ejb application being deployed on JBoss 7.1. Because
of this I was hoping to use  <at> Asyn and allow the container to really manage
the threads. This method would simply request the cached session insert the
Order fact, and start the jBPM process to process the Order. Perhaps this
part of the design is still flawed as I have only recently been thinking
about this and I would welcome all suggestions. 

Additionally is there any documentation on utilizing drools in a high
throughput environment(i.e white papers,etc.) This billing project is the
first of many potential projects we are looking to utilize drools for and I
would love to share some more documentation on this(as well as read on
myself). 

gboro54 wrote
> 
> Agreed that I can have a rule to retract the order....i was just thinking
> if the overhead of a reevaluation but can live with that...As far as the
> threading...this logic is going to be deployed on a jboss instance using
> ejb so I was thinking about, using the jboss thread pool...so when I say
> new thread it may not, be new put, pulled from a pool....does that sound
> reasonable?
> 
> 
> 
> laune wrote
>> 
>> Starting a new thread (if that's what you mean by process) for reusing
>> an existing session to process another order is likely to create more
>> overhead
>> and it'll just make threads compete for this resources.
>> 
>> Multiple threads each dedicated to a single session object might be a
>> better way to go.
>> 
>> I don't see any benefit to make simple order facts into events just for
>> the
>> sake
>> of making them expire automatically. There ought to be a well defined
>> state (or states) when processed orders are retracted by some rule.
>> 
>> -W
>> 
>> 
>> On 3 March 2012 14:11, gboro54 &lt;gboro54 <at> &gt; wrote:
>> 
>>> Mark,
>>>
>>>  I really appreciate the help and think I have come to a solution. Let
>>> me
>>> know if this sounds reasonable.
>>> 1. We will continue to use jBPM to coordinate the rules and business
>>> logic
>>> that need to occur in calculating charges for orders. However we will
>>> work
>>> the process to only work on a per order level.
>>> 2. All orders are associated with accounts. We will keep one
>>> knowledgebase
>>> as the rule sets are the same and we will partition sessions by
>>> accounts.
>>> The flow will go as follows:
>>> a. If the session exists insert the order, start a new process instance
>>> and
>>> fire all rules
>>> b. If the session has not been created: create the session, insert all
>>> reference data that will be used by all orders in executions of the rule
>>> set, insert the order, start a process, and fire all rules. This session
>>> is
>>> then cached(via a hashmap more then likely)
>>> c. This process will be invoked asyn from the main thread, allowing us
>>> to
>>> control the multithreading
>>> 3. Orders will be treated as an event and will be set to expire in a
>>> certain
>>> amount of time, allowing us to mange the memory footprint of each
>>> session.
>>>
>>> Does this sound reasonable based on what you know of our usecase?
>>> Additionally with expiring Orders does this cause a reevaluation of the
>>> rules when the expiration occurs? The only other question I have is does
>>> the
>>> expiration clock start when no more activation's get created for the
>>> given
>>> event?
>>>
>>> Thanks again.
>>>
>>> --
>>> View this message in context:
>>> http://drools.46999.n3.nabble.com/Drools-5-3-partitioned-rule-base-tp3793558p3795920.html
>>> Sent from the Drools: User forum mailing list archive at Nabble.com.
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users <at> .jboss
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>> 
>> _______________________________________________
>> rules-users mailing list
>> rules-users <at> .jboss
>> https://lists.jboss.org/mailman/listinfo/rules-users
>> 
> 

--
View this message in context: http://drools.46999.n3.nabble.com/Drools-5-3-partitioned-rule-base-tp3793558p3796689.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users


Gmane