Being in real-world production environment for many years, OpenRules Engine has a proven record of high efficiency and scalability. Several years ago some of our customers (a major European bank and a large government agency) assigned teams of people to do stress-testing of our product before they decided to use it instead of commercial counter-parts. The results were really good. For example, one report stated that OpenRules scaled to more than 300 concurrent users connected to one server providing us with the following results:

Actually we were not surprised, because by design one instance of the OpenRulesEngine can serve any number of concurrent user sessions. In 2006 an independent Japanese company reported efficiency comparison results of OpenRules with major commercial engines and they were in our favor even when other engines used a sequential mode. Especially good were OpenRules’ minimal memory requirements on the server.  The explanation was simple: with OpenRules you do not need a pool of rule engines and as a result, one instance of the OpenRulesEngine uses only minimally necessary memory to keep only single representation of all used rules.

In 2007 OpenRules introduced parameterized rules repositories that allowed a user to keep in memory only those versions of rules that expected to be actually used.  It further minimized memory requirements and improved OpenRules scalability.

In 2009 we made an additional improvement of OpenRulesEngine’s efficiency in multi-threaded environments supporting true parallelism.  Since then OpenRulesEngine constantly shows great efficiency and scalability in real-world multi-transactional environments.

However, last week our long-time customer noticed a growth of the server memory as they started to add more and more concurrent users.  The problem was not with the core OpenRulesEngine but rather with OpenRules Forms that became a foundation for their quite complex web-based GUI. OpenRules Forms uses the JSP technology incorporated into OpenRules BDMS. A user, who is not necessarily familiar with HTML or web design techniques, can use Excel to define layouts of all web pages in simple Layout tables along with validation and navigation logic presented in Rules tables.  By default, simple examples of web applications included in the OpenRules’ installation usually start a new engine for each new user. Our support team quickly switched to a mode that was supposed to use only one instance of the underlying OpenRulesEngine – it required changes only in the starting “index.jsp” file: we just have to be careful following the double-checked locking design pattern. However, we quickly found that the way we used our internal class Dialog (that maintains the state of every user session) did not work properly with a single instance of the OpenRulesEngine that serves concurrent sessions. It took a few nervous days but the problem was fixed, and now we again have a happy customer who is reporting no degradation in memory and well synchronized concurrent sessions.  If other customers experience any similar problems with OpenRules Forms or ORD, please contact support@openrules.com to receive this fix. The correct implementation will be included in the next release.