Problem With JSR-94 StatelessRuleSession release

[duffymo]

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.springframework.context.support.ClassPathXmlApplicationContext;
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;

      try
      {
         //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) iter.next();
            System.out.println("response: " + s);
         }
      }
      catch (Exception e)
      {
         e.printStackTrace();
      }
      finally
      {
         try
         {
            if (_session != null)
            {
               _session.release();
            }
         }
         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:

[pre]
"Agent reloader thread for com.blazesoft.server.local.NdLocalServiceAgentDisp enser@109ea96 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(Object.java:474)
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)
[/pre]

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.

%

[duffymo]

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

         try
         {
            if (ruleAdmin != null)
               ruleAdmin.deregisterRuleExecutionSet("jsrtest", new HashMap());
         }
         catch (Exception ignoreThis)
         {
            ignoreThis.printStackTrace();
         }

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?

%

[duffymo]

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)

%