11:27 p.m.
We are at 5.2.0 Final
We recently moved our rules server (written in-house) to its own Tomcat
instance. Some of our existing rules call a service to modify facts. With
the move of the rules server, these calls to the service no longer happen in
the working memory of the rules server. The rule must now capture the
return from the call to the remote service, in order to see the changes made
by the remote service call.
Within the rule, this change is working fine. The RHS was:
applicationService.applyInstruction($step);
as above, the $step fact would not be updated within the rule WM now that
the service is called remotely. However, when I changed this to
$step = applicationService.applyInstruction($step);
then $step did have the changes(I am verifying this by writing debug info to
the log). BUT, the object that was passed in to execute() on the knowledge
session did NOT have the changes. I have tried several things to fix this.
one was to update($step) but this failed with "Update error: handle not
found for object," I assume because the fact handle changed in the object
returned from the service call.
I also tried some variations on retracting and inserting the step:
retract($step);
$step = applicationService.applyInstruction($step);
insert($step);
and also tried using a different variable name:
retract($step);
$step2 = applicationService.applyInstruction($step);
insert($step2);
update($step2);
both these above did not get errors, but also did not cause the updated
object to return from session.execute() call.
To summarize:
in a call to execute() on a stateless knowledge session, an object is passed
in
a rule fires that calls a remote service that modifies the object
within the rule, we catch the changed object that is returned from the
service call
within the rule, the changes to the object ARE visible
on the return from execute(), the changes are NOT visible
thanks for your help...
--
View this message in context:
http://drools.46999.n3.nabble.com/how-to-update-object-modified-by-call-t...
Sent from the Drools: User forum mailing list archive at Nabble.com.
7:37 a.m.
On 27 July 2011 23:27, lhorton <LHorton(a)abclegal.com> wrote:
We are at 5.2.0 Final
The rule must now capture the
return from the call to the remote service, in order to see the changes
made by the remote service call.
Within the rule, this change is working fine. The RHS was:
applicationService.applyInstruction($step);
as above, the $step fact would not be updated within the rule WM now that
the service is called remotely. However, when I changed this to
$step = applicationService.applyInstruction($step);
This just changes a local (binding) variable; it does not change the object
the reference of which is availabe via the variable. (As in Java.)
then $step did have the changes(I am verifying this by writing debug info
to
the log). BUT, the object that was passed in to execute() on the knowledge
session did NOT have the changes. I have tried several things to fix this.
one was to update($step) but this failed with "Update error: handle not
found for object,"
The result of the RMI is an entirely new object, which you can't update.
I assume because the fact handle changed in the object
returned from the service call.
I also tried some variations on retracting and inserting the step:
retract($step);
$step = applicationService.applyInstruction($step);
insert($step);
The out-identifier of the "insert" command is bound to the fact handle
resulting from the original insert, so you can't get another object via this
identifier.
and also tried using a different variable name:
retract($step);
$step2 = applicationService.applyInstruction($step);
insert($step2);
update($step2);
both these above did not get errors, but also did not cause the updated
object to return from session.execute() call.
Same thing.
To summarize:
in a call to execute() on a stateless knowledge session, an object is
passed
in
a rule fires that calls a remote service that modifies the object
within the rule, we catch the changed object that is returned from the
service call
within the rule, the changes to the object ARE visible
on the return from execute(), the changes are NOT visible
You have several options.
1. Insert a second object Box { Step step;... } with an out-identifier and
do
retract($step);
$step = applicationService.applyInstruction($step);
insert($step);
modify( $box ){ setStep( $step ) }
With multiple Step objects being around, you'll have to use as many Boxes
and associate them with the original Step object as a second field.
2. Store the new $step into a global Box and use the getGlobal command.
3. Use the getObjects command, possibly with a filter to get only Step
objects.
-W
thanks for your help...
--
View this message in context:
http://drools.46999.n3.nabble.com/how-to-update-object-modified-by-call-t...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
7:22 p.m.
Thank you for the thorough explanation. Now that I understand what the RHS
syntax can (and cannot) do, I am taking option 4 which is to revise the RMI
call, and modify the fact within the rule rather than within the remote
method.
my rule now looks like this:
$instruction = applicationService.applyInstruction($step); // call now
returns an instruction
$step.setCurrentInstruction($instruction); // set the step's instruction
locally in the rule
I'll keep your other options in mind if we have a more complex RMI to
handle, but for this situation, the above code works and is easy to
understand & maintain.
thanks again
L.
--
View this message in context:
http://drools.46999.n3.nabble.com/how-to-update-object-modified-by-call-t...
Sent from the Drools: User forum mailing list archive at Nabble.com.
1:46 a.m.
I now have a more complex problem to solve involving this RMI issue and would
like some advice. I will state this as a simplified example to help explain
the problem.
Assume an object hierarchy:
there is a Job, which has two attributes, a name and a list of Step objects.
Each Step also has a name.
before rules execute, create an instance of Job with no name.
Add two Steps to the Job's step list: one step is named "one" and the
other
is named "two"
the knowledge session has a global named "rmiService" that is a remote
application service.
knowledge session also has a global named "results" that is a List (this is
my Box)
there are two rules:
rule1
when
$step : Step(name="one")
then
$step = rmiService.setJobName($step, "i belong to step one"); // sets the
name of the step's job
results.add($step);
end
rule2
when
$step : Step(name="two")
then
$step = rmiService.setJobName($step, "i belong to step two");
results.add($step);
end
call execute() on the session, passing in the Step objects.
assume that both rules fire. after execution, the results global contains
two objects: the step named "one" has a parent job with name "I belong to
step one" and step named "two" has a parent job with name "i belong to
step
two" - in other words, they no longer have the same parent Job.
I can't figure out how I can keep a hierarchy of objects updated when there
are multiple RMI calls in the same session.
--
View this message in context:
http://drools.46999.n3.nabble.com/how-to-update-object-modified-by-call-t...
Sent from the Drools: User forum mailing list archive at Nabble.com.
7:25 a.m.
There are two distinct ways of passing parameters: call by
value<http://de.wikipedia.org/wiki/Wertparameter>and call
by reference <http://de.wikipedia.org/wiki/Referenzparameter>;. Passing Java
objects blurs this distinction: the reference to the object is passed by
value, but the called method can modify the referred object arbitrarily. The
called method can *not* change the reference itself, i.e., the object
remains the same.
But what happens during a RMI? The stub on the client's side behaves as you
expect. But then the passed object is serialized, the data (not the object)
is sent away, and, eventually, some data comes back and is deserialized into
*another object. *And so this is, ultimately, a call by value, copying in to
and out from the remotely called method.
Each setJobName RMI creates a clone of Step - so at the end of this little
session you have 4 Step objects, the originals (still around as unchanged
facts) and the clones in your "results" list.
-W
Method
Step rmiService.setJobName( Step step,...)
could preserve object identity by copying all attributes of the deserialized
object into the "in" object.
(Alternatively, the service could pass the entire object hierarchy to
maintain integrity, but with parent and children being facts this would
complicate matters considerably.)
On 5 August 2011 01:46, lhorton <LHorton(a)abclegal.com> wrote:
I now have a more complex problem to solve involving this RMI issue
and
would
like some advice. I will state this as a simplified example to help
explain
the problem.
Assume an object hierarchy:
there is a Job, which has two attributes, a name and a list of Step
objects.
Each Step also has a name.
before rules execute, create an instance of Job with no name.
Add two Steps to the Job's step list: one step is named "one" and the
other
is named "two"
the knowledge session has a global named "rmiService" that is a remote
application service.
knowledge session also has a global named "results" that is a List (this is
my Box)
there are two rules:
rule1
when
$step : Step(name="one")
then
$step = rmiService.setJobName($step, "i belong to step one"); // sets the
name of the step's job
results.add($step);
end
rule2
when
$step : Step(name="two")
then
$step = rmiService.setJobName($step, "i belong to step two");
results.add($step);
end
call execute() on the session, passing in the Step objects.
assume that both rules fire. after execution, the results global contains
two objects: the step named "one" has a parent job with name "I belong to
step one" and step named "two" has a parent job with name "i belong
to step
two" - in other words, they no longer have the same parent Job.
I can't figure out how I can keep a hierarchy of objects updated when there
are multiple RMI calls in the same session.
--
View this message in context:
http://drools.46999.n3.nabble.com/how-to-update-object-modified-by-call-t...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4649
days inactive
4658
days old
4 comments
2 participants
participants (2)
-
lhorton -
Wolfgang Laun