[rules-users] is this kind of App right for DROOLS?
Greg Barton
greg_barton at yahoo.com
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
More information about the rules-users
mailing list