[rules-users] is this kind of App right for DROOLS?

Thu Apr 16 00:26:32 EDT 2009

Attached is an simple implementation of what I describe below.  I was pleasantly surprised that it ran much faster than I expected, and using less memory.  At times in pegged all four cpu cores on my workstation.  It's nice to see such effective utilization of resources. (Though I did run it with UseParallelGC, so that may have helped.)

The only complaint I have is getting it to stop. :)  You've got to kill or ctrl-C to get it to halt.  I am calling drools.halt() in a rule that is being executed.  Is there another way to exit from fireUntilHalt?  The console messages printed by the app show that fireUntilHalt does exit.

I noticed on doing a thread dump that a drools thread is blocking after fireUntilHalt exits:

Name: Thread-2
State: WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject at 4c7e8bf0
Total blocked: 0  Total waited: 414

Stack trace: 
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358)
org.drools.concurrent.CommandExecutor.run(CommandExecutor.java:77)
java.lang.Thread.run(Thread.java:619)

CommandExecutor.java line 77 is this:

Command executor = ( Command ) this.queue.take();

"queue" is a BlockingQueue, and BlockingQueue.take() will not exit until it returns an object from the queue or it's thread is interrupted.  Dev d00ds, is there an official way to interrupt this thread?

--- On Wed, 4/15/09, Greg Barton <greg_barton at yahoo.com> wrote:

> From: Greg Barton <greg_barton at yahoo.com>
> Subject: Re: [rules-users] is this kind of App right for DROOLS?
> To: "Rules Users List" <rules-users at lists.jboss.org>
> Date: Wednesday, April 15, 2009, 5:06 PM
> A more scalable solution may be this: load all transactions
> from site A, start the rule engine in a separate thread
> using fireUntilHalt, then start inserting the transactions
> from site B.  The rules should retract transactions that
> match up.  (This way ony roughly half of the transactions
> are in memory at any given time and you can scale twice as
> large.)  Once all B transactions have been inserted, what
> you have left are all trasnactions that haven't been
> able to match.  You can save them off and reload them if you
> want to attempt matching them in the next round of
> processing.
> 
> --- On Wed, 4/15/09, Learning BRMS
> <rulerhawk at gmail.com> wrote:
> 
> > From: Learning BRMS <rulerhawk at gmail.com>
> > Subject: Re: [rules-users] is this kind of App right
> for DROOLS?
> > To: "Rules Users List"
> <rules-users at lists.jboss.org>
> > Date: Wednesday, April 15, 2009, 4:34 PM
> > Uaw.. very nice example, Greg... Thanks
> > 
> > I really like these Drools solution. 
> > I will try your example with some more heavy class
> (with 40
> > attributes)
> > and expand the volume to 2.6 mi objects coming from a
> > hibernate
> > session.. 
> > 
> > I'll let you know.... I think I will enjoy those
> tests
> > :-D
> > 
> > Thanks again
> > 
> > Kris
> > 
> > On Tue, 2009-04-14 at 23:01 -0700, Greg Barton wrote:
> > > Yes, drools can handle this, and can handle the
> > volume.  You may want to consider sequential mode
> execution,
> > though.  See attached code for some simple matching
> rules. 
> > In the example there's a 5% chance a transaction
> with a
> > given id will not be present.  You could mock this up
> > further to have rules to handle matching in the case a
> > simple match isn't possible.
> > > 
> > > --- On Tue, 4/14/09, Learning BRMS
> > <rulerhawk at gmail.com> wrote:
> > > 
> > > > From: Learning BRMS
> <rulerhawk at gmail.com>
> > > > Subject: [rules-users] is this kind of App
> right
> > for DROOLS?
> > > > To: rules-users at lists.jboss.org
> > > > Date: Tuesday, April 14, 2009, 10:43 PM
> > > > Hi people...
> > > > 
> > > > I need to solve a problem on my work and I
> would
> > hear from
> > > > you if Drools
> > > > could help us... 
> > > > 
> > > > I have two kinds of "connected by
> > flatfile"
> > > > systems that register our
> > > > products selling transactions. 
> > > > 
> > > > We need to match dayly every selling
> transaction
> > against
> > > > both systems
> > > > and to track any difference for every store.
> 
> > > > 
> > > > An transaction could happens on system A and
> not
> > and system
> > > > B and
> > > > vice-versa and on different dates or times
> > (connection
> > > > problems could
> > > > delay the synchronizing). 
> > > > The transaction mostly have the same ID, but
> > there are
> > > > manual
> > > > transactions too with no id only date and
> > values... 
> > > > 
> > > > For each situation I have to fire a
> different
> > action
> > > > resolution (today
> > > > we have humanhand resolution).
> > > > 
> > > > We should have an 1 million of transactions
> by
> > day to
> > > > process... 
> > > > 
> > > > Today we are using a sql script to do
> reports
> > that will be
> > > > humanly
> > > > analyzed... 
> > > > 
> > > > I want to change this picture as soon as
> > possible...
> > > > 
> > > > Could Drools help us with this kind of
> analyze,
> > and support
> > > > this volume
> > > > of objects? 
> > > > 
> > > > How many objects could we have on working
> memory
> > at same
> > > > time for that
> > > > match?
> > > > 
> > > > Thanks a lot for any comments
> > > > 
> > > > Kris
> > > > 
> > > >
> _______________________________________________
> > > > 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 --------------
A non-text attachment was scrubbed...
Name: DroolsTest.java
Type: text/x-java
Size: 4100 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/rules-users/attachments/20090415/1bc7caf0/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Sample.drl
Type: application/octet-stream
Size: 867 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/rules-users/attachments/20090415/1bc7caf0/attachment.obj 