Announcement Announcement Module

Spring Modules forum decommissioned in favor of Spring Extensions

As the Spring Modules project has been replaced by the Spring Extensions ( project, this forum has been decommissioned in favour of Spring Extensions one at:

Please see the Spring Extensions home page for a complete list of current projects in Java, .NET and ActionScript. You can also propose one if you want.

Costin Leau
SpringSource - Spring Training, Consulting, and Support - "From the Source"
See more
See less
Problem With JSR-94 StatelessRuleSession release Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problem With JSR-94 StatelessRuleSession release

    I'm having a problem with the Spring JSR-94 module. I'm using Fair Issac's Blaze 5.5 as the rules engine. A co-worker has written a simple "Hello World" application to demonstrate the proper use of a Blaze rules engine with Spring, and it works just as advertised - except on cleanup.

    The rules engine does nothing more than take in a String, prepend "Hello ", and return the concatenated String as output:

     * Copyright (c) 2006 Your Corporation. All Rights Reserved.
    package qdjsrtest;
    import org.springframework.context.ApplicationContext;
    import org.springmodules.jsr94.rulesource.RuleSource;
    import javax.rules.RuleRuntime;
    import javax.rules.StatelessRuleSession;
    import java.util.HashMap;
    import java.util.Iterator;
    import java.util.LinkedList;
    import java.util.List;
    public class SpringTester
        * The following example calles a Blaze service named "jsrtest".  This service takes a single string argument and
        * returns the string with the word "Hello" prepended to it.
       public static void main(String[] args)
          StatelessRuleSession _session = null;
             //In a real application, these should be initialized once...
             ApplicationContext ctx = new ClassPathXmlApplicationContext("applicationContext.xml");
             RuleSource ruleSource = (RuleSource) ctx.getBean("ruleSource");
             //In a real application, you should create a new session for each request
             _session = (StatelessRuleSession) ruleSource.createSession("jsrtest", new HashMap(), RuleRuntime.STATELESS_SESSION_TYPE);
             //Yes, another Hello world!
             LinkedList list = new LinkedList();
             list.add(" world!");
             //GET THE RESULT
             List result = _session.executeRules(list);
             //DISPLAY THE RESULT
             Iterator iter = result.iterator();
             while (iter.hasNext())
                String s = (String);
                System.out.println("response: " + s);
          catch (Exception e)
                if (_session != null)
             catch (Exception ignoreThis) { ignoreThis.printStackTrace(); }
    The application runs fine, but when we release the session in a finally block the application never exits.

    When we dump the thread in IntelliJ, we see the following:

    "Agent reloader thread for com.blazesoft.server.local.NdLocalServiceAgentDisp [email protected] for service HCNU504F70Z:jsrtest.jsrtest" prio=5 tid=0x0b016a30 nid=0xb00 in Object.wait() [0x0b54f000..0x0b54fce8]
    at java.lang.Object.wait(Native Method)
    - waiting on <0x030857a0> (a java.lang.Object)
    at java.lang.Object.wait(
    at com.blazesoft.system.NdAsynchronousChannel.WjHzVuY (:148)
    - locked <0x030857a0> (a java.lang.Object)
    at com.blazesoft.system.NdAsynchronousChannel.take(:1 19)
    at com.blazesoft.system.NdAsyncRequestHandlerThread.g etRequest(:166)
    at com.blazesoft.system.NdAsyncRequestHandlerThread.W jHAfBE(:50)
    at com.blazesoft.system.NdAsyncRequestHandlerThread.r un(:136)

    It looks like the session thread is in a wait state and can't get out.

    Is the session release() all that's necessary to clean up this session? Do we need to do something else? Or is this a flaw in the Blaze implementation? Thanks.


  • #2
    Found A Solution; Wondering If It's Optimal

    Found a way to make the application stop: get the RuleAdministrator bean from the application context and call its deregisterRuleExecutionSet in a finally block:

                if (ruleAdmin != null)
                   ruleAdmin.deregisterRuleExecutionSet("jsrtest", new HashMap());
             catch (Exception ignoreThis)
    This requires that I know the rules server that I want to deregister. Is there a way to find out ALL the registered rules sets and iterate through them?

    Should this code be added to an ApplicationListener that shuts things down gracefully, or part of a destroy method?



    • #3
      Call Off The Dogs; Problem Solved

      Josh White got the answer: He pulled down the source from module 0.2, changed AbstractRulesSource to implement DisposableBean, and had me close the application context in the finally block instead of the session. Worked like a charm. Brilliant as usual, Josh.

      Is this the right approach? Common to Drools, JESS, etc.? Should this be added to Spring? Will Josh be given commiter status? 8)