Most interesting. Ernest has suggested the �session-specific fact� solution in the past. The light just went on for me with Ernest�s 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 impact.) What I think this means is that even if a Rete was threaded at the suggested level of granularity, the memory requirement would remain (effectively) the same. I believe this reduces the issue to managing the execution of the Rete for each connected client in the �session-specific fact� model. Specifically, for each thread represented by a Session object in the application server, how does one perform an atomic �assert/run/facts (observe the fact list at the end of the run)� sequence on a shared Rete network without serializing all requests? Is this not essentially what is accomplished by threading the Rete object itself? I believe that threading the Rete object would require a great deal of Ernest�s time. On that basis, I would be glad to pursue any suggestions on how execute the �atomic sequences� 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 quite 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 takes 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 configuration? > > Is this an urgent issue? > > > > Bob > > > > > > Alan Moore wrote: > > > > > Well, you should be able to detect a new session (see Session documentation) > > > 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 engine, > > > > 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
