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.ClassPathXmlAp plicationContext;
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:


"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)


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)

%