• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

[Jess] Jess and multithreaded apps

 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One of the big problems I have faced in using rule-based software in the past is that it has not coped well with multiple threads of execution running against the same knowledge base. In one application I worked on the rule engine (AION) imposed crazy architecture requirements simply because it came from a single-user desktop background and assumed a single thread of execution. This was completely inappropriate for a web application, but by the time we found out it was too late.
So my question is, how well does Jess cope in this situation. How much of Jess can be reused if there are 10, or 100, or even 1000 web browsers requesting answers from the same rulebase at the same time?
 
Sheriff
Posts: 6450
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was wondering the same thing. I found this on the Jess site though.
(Source of quote)

Note that each individual jess.Rete object represents an independent reasoning engine. A single program can then include several independent engines.
Jess can be used in a multithreaded environment. The jess.Rete class internally synchronizes itself using several synchronization locks. The most important lock is a global lock on all rule LHSs: only one assert or retract may be processing in a given jess.Rete object at a time. This restriction is likely to be relaxed in the future.

 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We've worked really hard over the years to make sure Jess works in densely multithreaded software. The most common mode of operation in Web/J2EE environments is for one thread to be executing or "firing" rules, while other threads add information to the working memory. Picture a big sieve, with stuff flowing out the bottom into a single chute, while multiple people dump baskets full of inputs into it.
Not only that, but Jess is "object oriented" (sounds very quaint to say this, but it's definitely not true of all commercial rule engines) so that you can create any number of individual, independent rule engines and use them all in the same JVM. You can have one engine per user, or a single engine can service any number of users.
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Mr. Friedman-Hill,

We are using Jess version 7.0b6 via the jsr 94 rules engine api and experiencing what appears to be a concurrency problem. Here is some context. We assert fairly complex java objects as facts into a StatelessRuleSession instance. The StatelessRuleSession objects are created by a factory that is thread-safe and we do not pool or resuse the StatelessRuleSession instances. In all cases, we use the StatelessRuleSession objects like so:

StatelessRuleSession ruleSession = RuleSessionFactory.getRuleSession(uri);

try
{
List facts = ...;
ruleSession.executeRules(facts);
}
finally
{
ruleSession.release();
}

The rules are designed to modify the facts. There are two types of facts, say type A and type B, a single list containing instances of A and B objects are passed to the executeRules method of the StatelessRuleSession object. The rules find a fact B that matches fact A and inserts the matching B object into the A object. The hashCode of A and B do not depend on each other. i.e. the hashCode is not modified by inserting an instance of A into B. When we execute our application in single-threaded mode, all the rules fire as expected and our tests pass. However, when our application accepts multiple requests (each in a separate thread) we occasionally experience the following behaviour:

1) rules not firing
2) B objects asserted into the RuleSession contains A objects asserted into a different instance of a RuleSession

We only see this behaviour when multiple requests are being handled by a given Java process in separate threads. We we send the same requests to our application in a serialized manner, we do not see this behaviour.

Does Jess reuse instances of StatelessRuleSession objects or retain state in some manner?

thanks in advance,

Jungho
 
Ernest Friedman-Hill
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Welcome to JavaRanch!

Although I sat on the expert group, I'm personally not a big fan of the javax.rules API; its semantics don't fit Jess especially well, and so the jsr94 "driver" provided by the jess.jsr94 package is a wrapper that not only has to do a bit more processing than I'd like, but also obscures what's really happening. We strongly encourage people to use Jess's native Java API.

The short answer is that although Jess itself has no problems in a multithreaded environment, the RuleSessions returned by current JSR94 driver implementation are not designed for concurrency. We hope to deal with this for the upcoming Jess 7 final release.
 
Jungho Kim
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Mr. Friedman-Hill,

Thank you for the prompt reply. To be clear, what I'm understanding is that the native Jess API does not maintain state upon being released. For example, multiple Rete instances will not share state. Therefore, as long as I create Rete objects within a thread and release the object upon using it, it will not share state across threads. If so, we will go ahead with removing the use of the jsr94 apis and use the Jess APIs directly.

regards,

Jungho
 
Ernest Friedman-Hill
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, that's exactly right. The problem with the current JSR94 driver is that a RuleExecutionSet corresponds to a single instance of the rule engine. If you create two StatelessRuleSessions with the same RuleExecutionSet, they share state, and that's not what you want. With the Jess native API, you can create as many independent rule engines (jess.Rete objects) as you desire.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic