6:04 p.m.
I have a RuleFlow that has some sequential steps at the beginning with a
couple of Gateways later in the flow.
When I run the flow through Eclipse, everything works fine and all the Rule
Task nodes are processed (and the underlying rules assigned to those
RuleFlowGroups are fired properly).
When I try to the flow using Drools-Server 5.1, only the first RuleFlowGroup
is fired. For example, I have an "Initialize" group followed by a
"Validate"
group. Only the rules belonging to the "Initialize" rule flow group get
activated. None of the "Initialize" rules get fired. When I reversed the
order in my RuleFlow, the "Validate" rules get fired, but not the
"Initialize."
I haven't been able to find anything online about this issue.
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/RuleFlow-only-calling...
Sent from the Drools - User mailing list archive at Nabble.com.
10:04 a.m.
I am new to Drools and I am having the exact same problem. Have you found any
resolution yet? How are you starting the ruleflow? I'm creating a
StartProcessCommand object and adding it to the BatchExecution Command. I am
not sending a FireAllRules command as this seems to make the rules fire
independently of the flow.
Basically I do something like this:
//create an insertCommand object and insert the passed in fact model into
it.
InsertObjectCommand insertCommand = (InsertObjectCommand)
CommandFactory.newInsert(factModel);
insertCommand.setObject(factModel);
//set the out identifier. This is a string that will be used to identify
//this particular fact model in the execution result response.
insertCommand.setOutIdentifier(factHandle);
insertCommand.setEntryPoint("DEFAULT"); //not sure what this does.
//tell the drools server to pass the fact model back to the client
//as part of the response
insertCommand.setReturnObject(true);
StartProcessCommand startProcessCommand = new StartProcessCommand();
startProcessCommand.setProcessId(processId);
commandList.add(startProcessCommand);
//add the command to the passed in array list
commandList.add(insertCommand);
BatchExecutionCommand batchCommand =
CommandFactory.newBatchExecution(commandList,knowledgeSession);
//Use the BatchExecutionHelper class to convert the batch command to an
XML stream to be sent to the
//drool-server's rest api.
String commandXML =
BatchExecutionHelper.newXStreamMarshaller().toXML(batchCommand);
Then I send the commandXML to the server using HttpClient. Is this similar
to what you do?
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/RuleFlow-only-calling...
Sent from the Drools - User mailing list archive at Nabble.com.
10:31 a.m.
I'm trying to understand the problem.
Can you share an isolated test and the process file? i will be happy to test
it and make it work..
Greetings.
On Thu, Feb 17, 2011 at 1:04 PM, rtmacphail <rtmacphail(a)gov.pe.ca> wrote:
I am new to Drools and I am having the exact same problem. Have you found
any
resolution yet? How are you starting the ruleflow? I'm creating a
StartProcessCommand object and adding it to the BatchExecution Command. I
am
not sending a FireAllRules command as this seems to make the rules fire
independently of the flow.
Basically I do something like this:
//create an insertCommand object and insert the passed in
fact model into
it.
InsertObjectCommand insertCommand = (InsertObjectCommand)
CommandFactory.newInsert(factModel);
insertCommand.setObject(factModel);
//set the out identifier. This is a string that will be used
to identify
//this particular fact model in the execution result
response.
insertCommand.setOutIdentifier(factHandle);
insertCommand.setEntryPoint("DEFAULT"); //not sure what this
does.
//tell the drools server to pass the fact model back to the
client
//as part of the response
insertCommand.setReturnObject(true);
StartProcessCommand startProcessCommand = new
StartProcessCommand();
startProcessCommand.setProcessId(processId);
commandList.add(startProcessCommand);
//add the command to the passed in array list
commandList.add(insertCommand);
BatchExecutionCommand batchCommand =
CommandFactory.newBatchExecution(commandList,knowledgeSession);
//Use the BatchExecutionHelper class to convert the batch
command to an
XML stream to be sent to the
//drool-server's rest api.
String commandXML =
BatchExecutionHelper.newXStreamMarshaller().toXML(batchCommand);
Then I send the commandXML to the server using HttpClient. Is this similar
to what you do?
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/RuleFlow-only-calling...
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
--
- CTO @ http://www.plugtree.com
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
10:58 a.m.
salaboy wrote:
I'm trying to understand the problem.
Can you share an isolated test and the process file? i will be happy to
test
it and make it work..
Greetings.
- Salatino "Salaboy" Mauricio -
I am going to try to create a simplified ruleflow that I can test to see if
I can reproduce the problem.
If the problem persists, I will share the configuration and package files.
Eric
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/RuleFlow-only-calling...
Sent from the Drools - User mailing list archive at Nabble.com.
8:01 a.m.
I found that my problem was that my drools-server knowledge session was
configured as a stateless session. In the knowledge-services.xml, the
default session was configured as follows:
<drools:ksession id="ksession1" type="stateful"
kbase="kbase1"
node="node1"/>
I changed it to:
<drools:ksession id="ksession1" type="stateless"
kbase="kbase1"
node="node1"/>
And now all my rules fire. (Also, I inserted a FireAllRulesCommand after my
StartProcessCommand) before invoking the server.
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/RuleFlow-only-calling...
Sent from the Drools - User mailing list archive at Nabble.com.
8:04 a.m.
Sorry, I meant that the other way around.
The default configuration was:
<drools:ksession id="ksession1" type="stateless"
kbase="kbase1"
node="node1"/>
I changed it to:
<drools:ksession id="ksession1" type="stateful"
kbase="kbase1"
node="node1"/>
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/RuleFlow-only-calling...
Sent from the Drools - User mailing list archive at Nabble.com.
9:09 a.m.
This is actually a problem with using Drools Flow in stateless sessions in
general, regardless of the Drools-Server.
See this post for details:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Flow-within-St...
This may be fixed in the trunk. I am not sure.
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/RuleFlow-only-calling...
Sent from the Drools - User mailing list archive at Nabble.com.
9:25 a.m.
New subject: RuleFlow only calling first RuleFlowGroup when called through drools-server
What are the implications of using a stateful sessions for my rule flows. Is there a
significant impact on resources? Will my fact model objects get cleaned up by garbage
collection after my flow has completed, or do they hang around indefinitely? Will the same
instance of a fact model be accessed the next time the rules in the flow are fired?
>> JeffMax <jeffmax(a)gmail.com> 2/18/2011 11:09 AM
>>>
This is actually a problem with using Drools Flow in stateless sessions in
general, regardless of the Drools-Server.
See this post for details:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Flow-within-St...
This may be fixed in the trunk. I am not sure.
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/RuleFlow-only-calling...
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
-------------------------
Statement of Confidentiality
This message (including attachments) may contain confidential or privileged information
intended for a specific individual or organization. If you have received this
communication in error, please notify the sender immediately. If you are not the intended
recipient, you are not authorized to use, disclose, distribute, copy, print or rely on
this email, and should promptly delete this email from your entire computer system.
9:31 a.m.
New subject: RuleFlow only calling first RuleFlowGroup when called through drools-server
My experience has been (and I believe the expected behavior of stateful
sessions) is that the state of your working memory will not be cleaned up
between flow executions. If,for example, one flow execution inserts a new
fact into working memory, then a subsequent flow execution would see that
fact in working memory.
For my requirements, which was to use Drools-Server as a stateless, request
- response server, with no shared state between requests, it was necessary
to use a stateless session.
- Jeff
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/RuleFlow-only-calling...
Sent from the Drools - User mailing list archive at Nabble.com.
10:40 a.m.
New subject: RuleFlow only calling first RuleFlowGroup when called through drools-server
Alright. So do I have to worry about contamination between rule flows.
Consider the following scenario:
1) Instantiate Fact Model A with property A = 10.
2) Insert Fact Model A into Working Memory
3) Start Process A.
4) Instantiate second instance of Fact Model A with property A = 20.
5) Start Process A again.
So are there now two separate instances of Fact Model A in working memory or is there
still only one instance and property A has been updated to 20? Will process B find the
correct value (20)? Is it thread safe? Will unused fact objects hang around forever?
Sorry if I'm being a little thick about this. Maybe I'm worrying about nothing.
Thanks for your response.
>> JeffMax <jeffmax(a)gmail.com> 2/18/2011 11:31 AM
>>>
My experience has been (and I believe the expected behavior of stateful
sessions) is that the state of your working memory will not be cleaned up
between flow executions. If,for example, one flow execution inserts a new
fact into working memory, then a subsequent flow execution would see that
fact in working memory.
For my requirements, which was to use Drools-Server as a stateless, request
- response server, with no shared state between requests, it was necessary
to use a stateless session.
- Jeff
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/RuleFlow-only-calling...
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
-------------------------
Statement of Confidentiality
This message (including attachments) may contain confidential or privileged information
intended for a specific individual or organization. If you have received this
communication in error, please notify the sender immediately. If you are not the intended
recipient, you are not authorized to use, disclose, distribute, copy, print or rely on
this email, and should promptly delete this email from your entire computer system.
1:33 p.m.
JeffMax wrote:
This is actually a problem with using Drools Flow in stateless sessions in
general, regardless of the Drools-Server.
See this post for details:
http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Flow-within-St...
This may be fixed in the trunk. I am not sure.
There are two issues posted in Jira about this.
https://issues.jboss.org/browse/JBRULES-2718
https://issues.jboss.org/browse/JBRULES-2728 (duplicate of 2718)
I am not sure if/when there is any plan to fix this in 5.1.x.
I may have to revert back to 5.0.1.
I was also going to try 5.2.0.M1 to see if it works, but a 5.2 FINAL release
is probably pretty far off, so I don't think that is a realistic
alternative.
Eric
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/RuleFlow-only-calling...
Sent from the Drools - User mailing list archive at Nabble.com.
10:34 a.m.
elitwin wrote:
There are two issues posted in Jira about this.
https://issues.jboss.org/browse/JBRULES-2718
https://issues.jboss.org/browse/JBRULES-2728 (duplicate of 2718)
I am not sure if/when there is any plan to fix this in 5.1.x.
I may have to revert back to 5.0.1.
I was also going to try 5.2.0.M1 to see if it works, but a 5.2 FINAL
release is probably pretty far off, so I don't think that is a realistic
alternative.
I decided to try using salience instead of RuleFlow to try to control the
order in which the rules fire. It is not ideal, but I thought I could get it
to work. However, I am seeing rules with higher salience firing after rules
with much lower salience. It doesn't consistently happen, but it seems that
salience is not very reliable across a large number of rules.
Still curious to know if there are plans to address the above issues (2718)
in 5.1.1. It seems like this is fairly important functionality.
Eric
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/RuleFlow-only-calling...
Sent from the Drools - User mailing list archive at Nabble.com.
11:22 a.m.
Activating and deactivating rules in batches (i.e., groups of one sort
or other) cannot be imitated by salience.
If you leave a group, no rule from that group stands a chance to
become active again. But a high-salience rule that isn't activated
before 0:12:34.567 may (after some firings of low-salience rules)
become activated at 0:12:34.567, after its LHS has finally made the
match point.
I have used agenda groups to achieve a flow of rule batches --- no
problem in 5.1.
-W
On 23 February 2011 17:34, elitwin <eric.litwin(a)pnmac.com> wrote:
elitwin wrote:
>
> There are two issues posted in Jira about this.
>
> https://issues.jboss.org/browse/JBRULES-2718
> https://issues.jboss.org/browse/JBRULES-2728 (duplicate of 2718)
>
> I am not sure if/when there is any plan to fix this in 5.1.x.
>
> I may have to revert back to 5.0.1.
> I was also going to try 5.2.0.M1 to see if it works, but a 5.2 FINAL
> release is probably pretty far off, so I don't think that is a realistic
> alternative.
>
>
I decided to try using salience instead of RuleFlow to try to control the
order in which the rules fire. It is not ideal, but I thought I could get it
to work. However, I am seeing rules with higher salience firing after rules
with much lower salience. It doesn't consistently happen, but it seems that
salience is not very reliable across a large number of rules.
Still curious to know if there are plans to address the above issues (2718)
in 5.1.1. It seems like this is fairly important functionality.
Eric
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/RuleFlow-only-calling...
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
5057
days inactive
5063
days old
12 comments
6 participants
participants (6)
-
elitwin -
JeffMax -
Mauricio Salatino -
Robby MacPhail -
rtmacphail
-
Wolfgang Laun