I think I understand. Program the Servlet thread to perform the following loop: 1) observe the current list of Session requests 2) assert to the shared Rete the appropriate fact(s) for each request. 3) Execute run() 4) dispatch the resulting (facts|data) to the Session based on session-id. I believe that saturation results in 100% CPU utilization only where there is no I/O performed in the Rete run. In our case, we interact (extensively) with SQL. Am I correct in assuming that a Servlet thread that runs the above loop on a pool of Rete instances (each it's own thread) would reduce mean response time? As always, many thanks for the exceptional support. BOb Ernest Friedman-Hill wrote: > Hi Bob, Alan, Fang, > > Actually, what I'm saying is that even this requirement (atomicity) is > unnecessary. Jess can easily reason about all sessions simultaneously, > as long as all the necessary facts are tagged with session-id values. > > (deftemplate shopping-cart > (slot customer-id) > (multislot items)) > > (deftemplate item > (slot catalog-number) > (slot name) > (slot price)) > > (defrule if-buying-expensive-speakers-recommend-gold-cables > (shopping-cart (customer-id ?id) (items $? ?num $?)) > (item (catalog-number ?num) (name "speakers") > (price ?cost&(> 300 ?cost))) > => > (recommend-to-customer ?id > "You should buy some gold speaker wires, too.")) > > My putative function recommend-to-customer calls a method on a Java > object representing the customer id (a session idemntifier.) > recommend-to-customer is probably written in Java and keeps Alan > Moore's hashtable of ids vs. ServletSessions. The servlet would assert > various facts, call Rete.run(), then compose the page based on > information deposited in the session by calls to things like > recommend-to-customer. > > The important point here is that many shopping-carts can peacefully > coexist at once. During any one call to run(), several shopping-carts > might get processed in some way or another, but that's just fine; > they're completely independent (until, perhaps, one actually checks > out and updates the inventory; this might trigger changes in other > carts. ) > > Eventually, of course, this system saturates. This happens when a run() > call starts to consume more time than the mean time between new client > requests. At this point, you're using 100% CPU, and need to buy a > load-balancing router! We should all be so successful :) > > I think Bob Johnson wrote: > > > > Most interesting. Ernest has suggested the =93session-specific fact=94 so= > > lution in the > > past. > > The light just went on for me with Ernest=92s statement: > > > > >These would of course all need to be > > >duplicated for each thread in Bob's proposed solution (in which > > >session-specific information would be made thread-local.) > > > > (Which he has previously pointed out, but I did not understand the full i= > > mpact.) > > What I think this means is that even if a Rete was threaded at the sugges= > > ted level > > of > > granularity, the memory requirement would remain (effectively) the same. > > > > I believe this reduces the issue to managing the execution of the Rete fo= > > r each > > connected client in the =93session-specific fact=94 model. Specifically,= > > for each > > thread > > represented by a Session object in the application server, how does one p= > > erform an > > atomic > > =93assert/run/facts (observe the fact list at the end of the run)=94 sequ= > > ence on a > > shared > > Rete network without serializing all requests? Is this not essentially wh= > > at is > > accomplished > > by threading the Rete object itself? > > > > I believe that threading the Rete object would require a great deal of Er= > > nest=92s > > time. > > On that basis, I would be glad to pursue any suggestions on how execute t= > > he > > =93atomic sequences=94 against a shared Rete without serializing. > > > > Bob > > > > > > > > Ernest Friedman-Hill wrote: > > > > > Hi all, > > > > > > I've pointed out before that another alternative is to use just one > > > Rete object and make sure that all the session-specific facts contain > > > a session-identifying slot. Then this one Rete can simultaneously > > > reason about all the clients' data. > > > > > > The 12 megabytes of Rete network consists mostly of complex indexed > > > data structures used to collect partial pattern matches (and probably > > > the matches themselves, too.) These would of course all need to be > > > duplicated for each thread in Bob's proposed solution (in which > > > session-specific information would be made thread-local.) > > > > > > Note that you can reduce the size of the Rete data structures, > > > possibly at the expense of some speed, using either the > > > set-node-index-hash function or the node-index-value defrule > > > declaration. These can reduce the size of some fixed arrays used in > > > each Rete join node. Try small prime values like 7 or 11 to see what > > > impact this has for you. it will have the largest impact on a system > > > with many rules and few partiual matches. > > > > > > In any case, using fairly generous numbers for sizes, assuming three > > > CEs per rule, ten tests per CE, 200 rules, I get about 1.4 MB for the > > > Rete network and about 25K for the Rete object itself. I think Bob's 12 > > > MB figure must include partial matches as well, which obviously would > > > need to be session-specific. > > > > > > I'll do a bit more investigating myself just to make sure there isn't > > > some massive memory hogging going on that I don't understand. > > > > > > I think Bob Johnson wrote: > > > > > > > > Alan is correct. However, each of these instances is likely to be qui= > > te large. > > > > In our case, rule sets on the order of 100-200 rules, > > > > each Rete is roughly 12 megabytes each. Not to mention the time it ta= > > kes to > > > > load the rules. I believe a threading solution is necessary for Jess = > > to be > > > > practical in the (inter|intra)net server environment. > > > > > > > > What fraction of the Jess population intends to deploy in this config= > > uration? > > > > Is this an urgent issue? > > > > > > > > Bob > > > > > > > > > > > > Alan Moore wrote: > > > > > > > > > Well, you should be able to detect a new session (see Session docum= > > entation) > > > > > and create a hashtable of Rete instances indexed by sessionId. > > > > > > > > > > > -----Original Message----- > > > > > > From: Fang Liu [mailto:[EMAIL PROTECTED]] > > > > > > > > > > > > HI, All: > > > > > > I have a servlet with one Rete instance on the server side. > > > > > > The problem > > > > > > is: usually there is one servlet instance per registered > > > > > > servlet name, > > > > > > which results in that all the clients have to share one Rete engi= > > ne, > > > > > > which is not what I want. So I am considering to use thread or > > > > > > implement javax.http.SingleThreadModel to solve this problem. > > > > > > Does anybody know how to do that? Any comments or examples > > > > > > will be very > > > > > > appreciated. > > > > > --------------------------------------------------------- > Ernest Friedman-Hill > Distributed Systems Research Phone: (925) 294-2154 > Sandia National Labs FAX: (925) 294-2234 > Org. 8920, MS 9012 [EMAIL PROTECTED] > PO Box 969 http://herzberg.ca.sandia.gov > Livermore, CA 94550
begin:vcard n:Johnson;Bob tel;fax:303 544 0373 tel;work:303 440 8833 x20 x-mozilla-html:FALSE url:www.streampoint.com org:Streampoint Financial Systems, Inc. version:2.1 email;internet:[EMAIL PROTECTED] title:V.P. of Product Development adr;quoted-printable:;;4940 Pearl East Circle=0D=0ASuite 200=0D=0A;Boulder;CO;80301; fn:Bob Johnson end:vcard
