XsltAction and maxThreads

[doudl]

I'm trying to use the XsltAction in a service where the only listener is a "scheduled-listener". When I deploy the module I get the following error:

Required configuration property 'maxThreads' not defined on configuration 'listener'.

I am able to use the XsltAction in other services without any issues.

To fix the problem I tried adding the 'maxThreads' attribute to the scheduled-listener but still received the error. I hooked up a debugger and put a break point at line 460 of XsltAction. The "parent" variable is not null and appears to be referencing the scheduled-listener, but the "_attributes" member variable (its a hashtable) of the parent does not contain the maxThreads attribute.

Tried to subclass XsltAction and override the getMaxThreadsFromParentConfigTree to work around the issue. Unfortunately the getMaxThreadsFromParentConfigTree method is "default" scope so I can't override the behavior to fix the problem.

Any ideas how I what I'm missing with respect to configurating the maxThreads?

My environment is:

ESB 4.8

JBoss 4.2.3

Java 5

Windows Vista

[kconner]

This sounds like a bug.  Can you create an issue in JIRA (https://jira.jboss.org/jira/browse/JBESB) and attach a quick example?  We'll take a look and get you a fix/workaround asap.

Kev

[doudl]

Kev,

Thanks for the quick response! I did find a work around. Instead of using XsltAction I used Smooks to apply the stylesheet.

It might be next week before I have a moment to create a simple example to recreate the issue. Though I might be able to post the contents of the parent config (from the debugger) that is missing the maxThreads sooner.

Leon

EDIT:

The issue has been created for tracking.

https://jira.jboss.org/browse/JBESB-3330

[dward]

Leon,

Did you ever create an example, even though you're using a workaround?  If not, I can create one easily enough.

Kev,

A couple things I found interesting:

1. Inside XsltAction's getMaxThreadsFromParentConfigTree(ConfigTree):int method, the parent config takes precedence over the child (current) config.  Doesn't that seem backwards?
2. In ScheduledListener cases, how would setting the maxThreads property even apply?  The reason I ask is that according to the documentation, one configures the threads via Quartz Scheduler Property Configuration:
   • org.quartz.threadPool.threadCount = 2
   • org.quartz.threadPool.threadPriority = 5
   • etc...

Now, the simple fix for this bug would be too change XsltAction's use of getRequiredAttribute(MAX_THREADS_TAG) to getAttribute(MAX_THREADS_TAG, "1"), however I'd appreciate your feedback on the couple things I mentioned above first.

Thanks,

David

[kconner]

Inside XsltAction's getMaxThreadsFromParentConfigTree(ConfigTree):int method, the parent config takes precedence over the child (current) config.  Doesn't that seem backwards?

The maxThreads for the pipeline would be on the parent configuration, you wouldn't normally have one for the action.  I suspect that the current one is being queried for unit test purposes rather than normal pipeline operation, but we should tidy it up.

In ScheduledListener cases, how would setting the maxThreads property even apply?  The reason I ask is that according to the documentation, one configures the threads via Quartz Scheduler Property Configuration:

Those are for the general quartz thread pool, whereas we would only expect a single thread processing for our scheduled listeners.

Now, the simple fix for this bug would be too change XsltAction's use of getRequiredAttribute(MAX_THREADS_TAG) to getAttribute(MAX_THREADS_TAG, "1")

I suspect this is all that is required to be honest.

Kev

[dward]

JBESB-3330 has been closed.  The attribute is no longer required, and will default to "1".  The javadoc was also tweaked to better explain it's behavior.

[doudl]

Wow that was fast. Last week was a busy one for me and I just finished a simple example to reproduce the problem this morning. Are you still interested in the example?

[dward]

.. I just finished a simple example to reproduce the problem this morning. Are you still interested in the example?

Yes please. I would like to personally run it against my trunk build to give me yet another "warm and fuzzy".    You can attach the zipped up example to this forum thread. I will probably end up re-opening the jira just long enough to attach it to that issue, so that QA has something to validate against if they want.  Thanks again.

[doudl]

Attached is the deployment ESB directory (XsltThreads.esb.zip) and the Eclipse ESB project to produce it (XsltThreads.zip).

[dward]

Leon,

Thanks for the test case.  I had to tweak them in a couple ways, though.  Specifically, add a body to the composed message, and change the actions mep to OneWay.  The fix worked for the test case.  I then re-packaged up the files and attached them to JBESB-3330.

Thanks again,

David