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.
_________________________________________________________________________
15 years, 7 months
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?
--
唐睿
15 years, 7 months
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.
_________________________________________________________________________
15 years, 7 months
Exception Thrown When Dispose KSession in JPA Persistence Environment
by Rui Tang
Hi list,
I have a simple program using drools-persistence-jpa library.
StatefulKnowledgeSession session = null;
try {
ksession = JPAKnowledgeService.newStatefulKnowledgeSession(this.kbase,
null, env);
ksession.execute(myCustomCommand);
} finally {
if (ksession != null) {
ksession.dispose();
}
}
if ksession.execute statement throws an exception, then ksession.dispose
statement will throw another fancy exception like this:
java.lang.RuntimeException: Could not find session data for id 473
at
org.drools.persistence.session.SingleSessionCommandService.initKsession(SingleSessionCommandService.java:183)
at
org.drools.persistence.session.SingleSessionCommandService.execute(SingleSessionCommandService.java:272)
My environment is like following:
1. I use JTA to manage tx across several sessions.
2. I set a global EntityManagerFactory, TransactionFactory and a
UserTransaction to the env variable when initialize the ksession.
I think this exception occurred because of this:
When I execute my custom command, a user tx is opened, but when exception
occurs, this tx is rolled back. But in ksession.dispose statement, it will
use the uncommited session id to retrieve the persisted ksession, then
exception is thrown.
My questing is that, do I really need to put ksession.dispose in the finally
block to force the ksession to dispose even when exception occurred. If not
won't that matter? If yes how to deal with the exception, add another
try/catch block around the ksession.dispose statement?
Thank you in advance.
--
唐睿
15 years, 7 months
Re: [rules-users] Rules selection logic
by Greg Barton
Also, the use of doubles in an == test is problematic. Not that it would cause this particular problem, but it will cause others.
GreG
On Nov 13, 2010, at 11:52, Wolfgang Laun <wolfgang.laun(a)gmail.com> wrote:
Are you using the latest (5.1.1) release?
Is the duplicated rule in another DRL file and does it have exactly the same name? If so, it simply overwrites the first rule.
If it's different, please create a JIRA with a minimized example reproducing the error.
-W
On 13 November 2010 14:12, balagh <bala.ganesh(a)accenture.com> wrote:
Hi,
Below is the DRl used. When i have two different rules with the same below
DRL, only one rule is getting executed. I could find that in my logs. If i
change the line to Ransome(amr <= 10) in any one of the rule, both of them
are getting executed.
I am having the rules in db and the execution trace log will have the rules
no which gets executed
Rule "rule -1"
when
loose : Loose()
ransome : Ransome(amt == 6.15) from loose.getRansomeArray(0)
util : Util()
then
util.doIt(loose, "Hello");
end
Thanks,
Bala
--
View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Rules-selection-logic...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
15 years, 7 months
Rules Flow production level support
by Prafull Kumar
Hi All,
I would like to know the possible options of production level support for Drools
Flow 5.1. Please share the links if support is available from JBoss or any 3rd
party.
Regards, Prafull
15 years, 7 months
Fw: Rules Flow Eclipse editor
by Prafull Kumar
Hi All,
I would like to know how we can modify the Rules flow eclipse editor look and
feel and functionality. e.g. If we have a Embedded Sub-Process in the flow and
reduce the size of it, the arrows are still displayed in the main canvas. Please
see the attached snapshot for reference.
How we can fix it? also if we want to open the Embedded Sub-Process in a new
window for easy maintainability/readability of the very complex processes, how
we can achieve it?
Going forward we are also looking to create the custom editor for the nodes.
Please guide us if its possible and there is any document for this.
Regards, Prafull
15 years, 7 months
