5.1.1: ArrayIndexOutOfBoundsException in org.drools.core.util.AbstractHashTable
by Lubos
Exception occures at:
org.drools.core.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:317)
in Drools 5.1.1 when calling insert() on just created
StatefulKnowledgeSession.
I found similar issues reported for LeftTupleIndexHashTable, it had to do
with initializing row to -1 instead of 0 or something similar. I see that
fixed in Left/RightTupleIndexHashTable but it seems to me like it is still
present in AbstractHashTable.
The bug occures randomly (inserting the same data), usualy under load. The
index is either -1 or too high. I create multiple sessions in threads from
one KnowledgeBase, sessions are not shared.
Stack trace I got is:
java.lang.ArrayIndexOutOfBoundsException: 16
at
org.drools.core.util.AbstractHashTable$HashTableIterator.next(AbstractHashTable.java:317)
at
org.drools.reteoo.EntryPointNode.updateSink(EntryPointNode.java:323)
at
org.drools.reteoo.ObjectTypeNode.attach(ObjectTypeNode.java:303)
at
org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:257)
at
org.drools.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:92)
at
org.drools.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:68)
at
org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:981)
at
org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:917)
at
org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:251)
I am not sure if this post belongs here, sorry if not.
Thanks for help/suggestions
Lubos
--
View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/5-1-1-ArrayIndexOutOf...
Sent from the Drools - User mailing list archive at Nabble.com.
14 years
Re: [rules-users] rules-users Digest, Vol 48, Issue 34
by Dennis Duggan
Wolfgang:
In the rule??
rule "Match"
when
$oRecord1 : MyObject1( )
$oRecord2 : MyObject2(RefID==$oRecord1. RefID )
then
$oRecord1.setStatus( "Matched" );
$oRecord2.setStatus( "Matched" );
modify ( $oRecord1 ) { status = "Matched" };
modify ( $oRecord2 ) { status = "Matched" };
end
I get an error...
__obj__.status cannot be resolved or is not a field
Doesn't the setStatus calls just above update the object?
Thanks!
Dennis
-----Original Message-----
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of rules-users-request(a)lists.jboss.org
Sent: Tuesday, November 09, 2010 3:39 PM
To: rules-users(a)lists.jboss.org
Subject: rules-users Digest, Vol 48, Issue 34
Send rules-users mailing list submissions to
rules-users(a)lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/rules-users
or, via email, send a message with subject or body 'help' to
rules-users-request(a)lists.jboss.org
You can reach the person managing the list at
rules-users-owner(a)lists.jboss.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of rules-users digest..."
Today's Topics:
1. Re: Query query... (Dennis Duggan)
2. Re: Query query... (Wolfgang Laun)
----------------------------------------------------------------------
Message: 1
Date: Tue, 9 Nov 2010 14:13:07 -0600
From: Dennis Duggan <dennis(a)esptechnologies.com>
Subject: Re: [rules-users] Query query...
To: "rules-users(a)lists.jboss.org" <rules-users(a)lists.jboss.org>
Message-ID:
<121AF5D37A73F94E98B26D237302319E010A76863B(a)MBX04.exg5.exghost.com>
Content-Type: text/plain; charset="us-ascii"
I have a super interface, that both objects implement.
The matching rule looks like:
rule "Match"
when
$oRecord1 : MyObject1( )
$oRecord2 : MyObject2(RefID==$oRecord1. RefID )
then
$oRecord1.setStatus( "Matched" );
$oRecord2.setStatus( "Matched" );
end
I can breakpoint right after running the query and I see objects with all statuses so the matching rule is firing correctly.
Thanks!
Dennis
Dennis Duggan
Principal Software Engineer, Software Engineering
ESP Technologies Corp. "THE Buy-Side Solution"
One Indian Head Plaza Suite 701, Nashua, NH 03060
603.324.2444 ext. 1304 Office | 603.324.2447 Fax
dennis(a)esptechnologies.com
ESP Technologies, winner 2009 Red Herring North America 100 and 2008 Deloitte Technology Fast 500.
This e-mail and/or attachments may contain privileged, confidential or proprietary information. Unintended recipients should notify the sender immediately and delete. Disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. Brokerage services provided by Electronic Securities Processing (ESP) LLC. Member FINRA, SIPC. This is neither an offer or recommendation to buy or sell any security or other financial instrument. Email compliance(a)esptechnologies.com with questions regarding this disclosure.
From: Dennis Duggan
Sent: Tuesday, November 09, 2010 1:55 PM
To: 'rules-users(a)lists.jboss.org'
Subject: Query query...
I have 2 types of objects in my knowledge base that I am trying to equate. Equality is based on a number of different variables contained in the objects. Once I find equal objects I set a status member in each to "Matched", otherwise it will be "OneKnows" or "TwoKnows".
After I fire the rules I use queries that I call from Java code to get the three different types of objects.
query "OneFirmKnows"
oRecord : MyObject1( status=="OneKnows" )
end
query "TwoKnows"
oRecord : MyObject2( status=="TwoKnows" )
end
query "Matched"
oRecord : MyObject1( status=="Matched" )
end
Each query sends back all objects no matter what the status is. The objects have a getStatus( ) method. What am I doing wrong?
Thanks!
Dennis
14 years
Re: [rules-users] Drools STREAM Mode performance with rather simple rule
by Roess. Oliver
Hello again.
Thanks for your test Wolfgang. When I do it like you did, I get approx.
the same results. But you misunderstood my scenario. I don't want to
send ABC x times. Here's what I meant in pseudocode.
for ( i = 0; i < X; i++)
Send Y times A
Send Y times B
Send Y times C
I dropped the idea of calling fireUntilHalt() and now I call
fireAllRules after every single insert, just to be quick. This avoids
the problem of getting random execution durations. Now I produce nearly
constant times every time I execute this. But it is still not very
satisfying. These are just a few hundred events. In a real business
scenario it will be a lot more. Increasing X will cause the time to go
up linearly which is ok, but increasing Y will have the time go up
overproportional, which is not acceptable. We will evaluate this now
with a really good machine. But it would be interesting to see what
results others achieve in this scenario.
Best regards,
Oliver
_________________________________________________________________________
SEEBURGER AG Vorstand/Seeburger Executive Board:
Sitz der Gesellschaft/ Bernd Seeburger, Axel Haas, Michael Kleeberg
Registered Office:
Edisonstrasse 1 Vorsitzender des Aufsichtsrats/Chairperson of
D-75015 Bretten the Seeburger Supervisory Board:
Tel.: 07252 / 96-0 Dr. Franz Scherer
Fax: 07252 / 96-2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: info(a)seeburger.de HRB 240708 Mannheim
_________________________________________________________________________
Dieses E-Mail ist nur fur den Empfanger bestimmt, an den es gerichtet
ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes
Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungs-
au?erung ist die des Autors und stellt nicht notwendigerweise die
Sind Sie nicht der Empfanger, so haben Sie diese E-Mail irrtumlich
erhalten und jegliche Verwendung, Veroffentlichung, Weiterleitung,
Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt.
Weder die noch der Absender (Oliver Roess)
ubernehmen die Haftung fur Viren; es obliegt Ihrer Verantwortung,
die E-Mail und deren Anhange (0) auf Viren zu prufen.
The present email addresses only the addressee which it targets and
may contain confidential material that may be protected by the
professional secret. The opinions reflected herein are not necessarily
If you are not the addressee, you have accidentally got this email and
are not enabled to use, publish, forward, copy or print it in any way.
Neither the , nor the sender (Oliver Roess) are
liable for viruses, being your own responsibility to check this email
and its attachments (0) for this purpose.
_________________________________________________________________________
14 years
Reasoning with past events
by Anais Martinez
I'm using Drools for a system of alarms on agriculture. I am considering
several parcels, whose plants can be on different status (for example,
sprouting, flowering, etc.). These statuses are updated automatically by
rules, controled by several calendars. In the other hand, the farmer is
allowed to change the plants' status by hand if he/she observes that real
plants are in a status in the terrain.
If the farmer set the status before the automatic change, there is no
problem: the rules corresponding to the new state become active and the
automatic change has no effect. But if the farmer changed the status after
the automatic change, how would I consider the events in the period of time
between automatic and hand changes?
Thanks in advance.
--
View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Reasoning-with-past-e...
Sent from the Drools - User mailing list archive at Nabble.com.
14 years
help
by Roess. Oliver
_________________________________________________________________________
SEEBURGER AG Vorstand/Seeburger Executive Board:
Sitz der Gesellschaft/ Bernd Seeburger, Axel Haas, Michael Kleeberg
Registered Office:
Edisonstrasse 1 Vorsitzender des Aufsichtsrats/Chairperson of
D-75015 Bretten the Seeburger Supervisory Board:
Tel.: 07252 / 96-0 Dr. Franz Scherer
Fax: 07252 / 96-2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: info(a)seeburger.de HRB 240708 Mannheim
_________________________________________________________________________
Dieses E-Mail ist nur fur den Empfanger bestimmt, an den es gerichtet
ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes
Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungs-
au?erung ist die des Autors und stellt nicht notwendigerweise die
Sind Sie nicht der Empfanger, so haben Sie diese E-Mail irrtumlich
erhalten und jegliche Verwendung, Veroffentlichung, Weiterleitung,
Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt.
Weder die noch der Absender (Oliver Roess)
ubernehmen die Haftung fur Viren; es obliegt Ihrer Verantwortung,
die E-Mail und deren Anhange (0) auf Viren zu prufen.
The present email addresses only the addressee which it targets and
may contain confidential material that may be protected by the
professional secret. The opinions reflected herein are not necessarily
If you are not the addressee, you have accidentally got this email and
are not enabled to use, publish, forward, copy or print it in any way.
Neither the , nor the sender (Oliver Roess) are
liable for viruses, being your own responsibility to check this email
and its attachments (0) for this purpose.
_________________________________________________________________________
14 years
Some Code Problem about SingleSessionCommandService
by Rui Tang
Hi list,
During my application development, I encountered some problems about the
exception handling within SingleSessionCommandService class.
In this constructor
public SingleSessionCommandService(KnowledgeBase kbase,
KnowledgeSessionConfiguration conf,
Environment env) {
the exceptions are handled like this
try {
....
} catch ( Exception t1 ) {
try {
this.txm.rollback(); // line 1
} catch ( Throwable t2 ) {
throw new RuntimeException( "Could not commit session or rollback",
t2 ); // line 2
}
throw new RuntimeException( "Could not commit session", t1 ); // line 3
}
In the first try block, if some exception occurred, exception t1 will be
caught, then this.txm (TransactionManager) will be rolled back. But during
this piece of code, if exception occurred again, throwable t2 will be
caught, then t2 will be wrapped into another runtime exception and re-throw.
In this case the wrapped t1 (in line 3) will never be throw out. But in my
situation, the wrapped t1 exception will be more meaningful than the wrapped
t2 exception.
So I think this code should be changed like this:
try {
...
} catch (Exception t1) {
try {
this.txm.rollback();
} catch (Throwable t2) {
logger.error(t2.getMessage(), t2); // or some other logs, but do NOT
rethrow
}
throw new RuntimeException( "Could not commit session", t1
}
Is this right?
--
唐睿
14 years
Drools STREAM Mode performance with rather simple rule
by Roess. Oliver
Hello everyone.
I've got a question regarding the performance of Drools in STREAM mode.
It seems to me, that either Drools is not very fast here, or the problem
is with the rule itself.
This is the rule.
rule "ABC"
no-loop
when
$a : Aevent()
$b : Bevent(id == $a.id)
$c : Cevent(id == $a.id)
then
retract($c);
retract($a);
retract($b);
...(actions)
end
It basically says: act upon every group of A, B and C events with the
same ids. The retract statements will make sure, none of these events
will get matched again by this rule. Side question: is there any
possibility to do this rule without the retractions?
Regarding the performance:
If I put the arriving events in this sequence: A(x), B(x), C(x) where x
is the number of events being sent. No other events than A, B and C with
the same id being sent. And I repeat this sequence a small number of
runs (12 times in a row), then it will take Drools:
For x=8, on average 3 seconds to detect all 96 patterns,
for x=16, on average 30 seconds to detect all 192 patterns.
But the average is not very meaningful. Sometimes the Engine does it in
(x=16) 10 seconds, and sometimes it takes him over a minute to detect
everything, sometimes it takes him nearly forever for no reason. We
tested this on different machines and we cannot predict a "stable"
behaviour. We figured out, that this instability might come from
fireUntilHalt, which we invoke from a separate thread. Some ABC groups
get detected faster than others and the total duration is totally
variable as stated before.
When calling fireAllRules upon every insert, the total duration is
stable (4,5 sec for x=16 and 12 runs) and also the detection time for
every ABC group seems to be even.
So a few questions: whats the problem with fireUntilHalt? Are we using
it the wrong way? If fireAllRules is used after every insert, can rules
be triggered by actions of other rules? For event stream processing a
solution that fires almost always is desirable.
Why is the overall performance so poor? If I do x=32 and do just one
run, which means just a total of 32*3= 96 events being sent and it takes
him 2,6 seconds to detect all 32 patterns. That's not very fast, is it?
I'm using Drools 5.1.1 and the latest JDK.
It would be nice to get some opinions.
Best regards,
Oliver
_________________________________________________________________________
SEEBURGER AG Vorstand/Seeburger Executive Board:
Sitz der Gesellschaft/ Bernd Seeburger, Axel Haas, Michael Kleeberg
Registered Office:
Edisonstrasse 1 Vorsitzender des Aufsichtsrats/Chairperson of
D-75015 Bretten the Seeburger Supervisory Board:
Tel.: 07252 / 96-0 Dr. Franz Scherer
Fax: 07252 / 96-2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: info(a)seeburger.de HRB 240708 Mannheim
_________________________________________________________________________
Dieses E-Mail ist nur fur den Empfanger bestimmt, an den es gerichtet
ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes
Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungs-
au?erung ist die des Autors und stellt nicht notwendigerweise die
Sind Sie nicht der Empfanger, so haben Sie diese E-Mail irrtumlich
erhalten und jegliche Verwendung, Veroffentlichung, Weiterleitung,
Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt.
Weder die noch der Absender (Oliver Roess)
ubernehmen die Haftung fur Viren; es obliegt Ihrer Verantwortung,
die E-Mail und deren Anhange (0) auf Viren zu prufen.
The present email addresses only the addressee which it targets and
may contain confidential material that may be protected by the
professional secret. The opinions reflected herein are not necessarily
If you are not the addressee, you have accidentally got this email and
are not enabled to use, publish, forward, copy or print it in any way.
Neither the , nor the sender (Oliver Roess) are
liable for viruses, being your own responsibility to check this email
and its attachments (0) for this purpose.
_________________________________________________________________________
14 years
