Hi!
> Does this single thread block or does it fully utilize the CPU? I mean,
> if a rule involves a request to an external web/database server, does the
> thread simply wait for the request to return or process other rules while
> waiting? What happens if a particular LHS takes a really long time to
> return (involves a big database query)?
Do you mean LHS or RHS? In the context of this discussion there is an important
difference. LHS pattern matching, including backwards chaining, is performed in the
context of the thread(s) asserting the facts. The RHS is executed by the thread
calling run() or runUntilHalt().
Whether or not your thread gets blocked depends on what you'r doing. Usually, threads
get blocked while waiting for I/O. So, if your thread's waiting for a long-running
database query to return some results, there are two cases:
(1) LHS-processing: the specific thread blocks, e.g. waiting for a database query
during backwards chaining. Other threads can proceed asserting facts, etc.
(2) RHS-processing: the single thread used for RHS processing blocks waiting.
RHS-processing doesn't continue until the waiting thread wakes up and resumes.
You should try to avoid "overlapping" RHS execution by multiple threads. For
independent requests you can always use multiple engines with the same set of
templates, rules, etc.
For each engine it's safe to have multiple concurrent "LHS threads" and a single "RHS
thread".
> Even if the thread doesn't get blocked, it seems like you should be able
> to have multiple threads/processors running in parallel on the same
> context (otherwise you get sub-optimal performance on multi-processor
> CPUs).
See above.
> > If you want to actually process requests in parallel then you'll need
> > an engine pool. Otherwise, you'd need to explicitly structure your rules
> > in a way that leverages the inherent parallelism.
>
> What does it mean to leverage the inherent parallelism? If two different
> threads assert a request into the same running Rete object, what happens?
Imagine a single thread executing two different requests in parallel. Assume that
during request execution there are some points where that thread (client) gets blocked
waiting for some server to reply.
When client/server communication is synchronous, the client will just sit there
waiting for the server to reply. In the asynchronous case the client would only send
the request and then continue with processing the second request without waiting for
the reply. Server replies would be stored in a queue and could be read by another
thread that converts them to facts. So, basically, you could split up your rules at
the points where blocking client/server communication or I/O takes place.
Simple example:
;; Single rule with blocking RHS
(defrule business-rule-1
(request-fact ...)
(condition-fact ...)
=>
(action-1 ...)
(synchronous-client-server-interaction ...)
(action-2 ...))
;; Multiple rules with non-blocking RHS
;; Assume (synchronous-client-server-interaction ...) is split up in three parts:
;; (pre-request-action ...) (send-request ...) (post-request-action ...)
;;
(defrule business-rule-1
(request-fact ...)
(condition-fact ...)
=>
(action-1 ...)
(pre-request-action ...)
(send-request ...))
(defrule business-rule-2
(server-reply ...)
; you might need to match request and condition at this point
=>
(post-request-action ...)
(action-2))
> > > 2. what is the best way to pass an HttpServletRequest into Jess?
> >
> > You were talking about a business logic servlet. Why does it need to
> > know anything about HTTP requests? I'd rather hide that in some
> > interface that translates the requests in a form most suitable for
> > processing by business rules.
>
> I agree that was why I gave a proposed template in the last mail.
> My feeling is that I don't know enough to get very clever about
> HttpServletRequest abstraction. If I can get the basic request object
> into the Jess in a reasonable format, I will evolve transformation rules
> that I can optimize out into linear java code later.
> The big question here is: Do I want to process Java Hashtable in the LHS
> of the rules? is there a better way of passing name-value pairs into
> jess?
You should not process Java Hashtables. This would complicate things a lot.
Performance wouldn't be optimal , too.
Basically, a HTTP requests consists of some request name and a set of name/value
pairs. Right? So, requests can be transformed into unordered facts. Templates and
rules would have the following form:
(deftemplate _request
(slot <control-slot-1> ...)
...
(slot <control-slot-M> ...))
(deftemplate <request-name> extends _request
(slot <name-1> (type <type-1>) (default <default-1>))
...
(slot <name-N> (type <type-N>) (default <default-N>)))
(defrule process-<request-name>
(<request-name> (<name-1> ?value-1) ... (<name-N> ?value-N))
...
=>
...)
Request facts can be easily generated from HTTP requests. I'd do this in Java.
> > > 3. how do I clean up after processing a request (so I don't accumulate a
> > > large number of obsolete request facts)?
> >
> > You can usually retract request and control facts right after you've
> > "used" them. You can also proceed in a sequence of phases, the last one
> > being the "cleanup phase". Somebody posted a set of rules to the list,
> > that provide a framework for phase control.
>
> I looked up phase control and did not see much. Can you give a more
> direct reference? Is there a way a RHS can get a list of all facts used
> to fire it? Then you could accumulate a list of facts to dump.
I've forwarded you the original mail.
Concerning access to LHS facts from the RHS:
(defrule my-rule
?fact-1 <- (my-fact-1 ...)
...
?fact-N <- (my-fact-N ...)
=>
(retract ?fact-1 ... ?fact-N)
Greetings, Thomas
---------------------
Dipl.-Inform. Thomas Barnekow
Mobil: +49 (0) 172 / 7126018
E-Mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
