My Action gets constructed twice

[quintona]

Hi,

I am running ESB 4.7 inside JBoss AS 5.1. In our production system there is a strange effect where each of the actions configured in the ESB as constructed twice. Obviously this creates quite a few downstream issues with duplicate resources.

Can anyone think of any reason why the ESB would be creating two instances of each of my action classes?

Thanks!

[tfennelly]

My guess would be that the actions are actually configured twice in the system somewhere e.g. you have something deployed that shouldn't and it contains a config of these actions too.

Things to try:

1. Check your system and make sure you don't have additional .esbs or services deployed, that shouldn't be.
2. I think the monitoring tools would give you a visual of your running system... what deployments are there... what services are on those deployments... what actions are on the services etc.

[quintona]

Hi Tom,

Thanks for the prompt response. Much appreciated.

I have verified that there are no extra esbs deployed. I have performed the same test with smaller sandbox applications (some I created for ESB articles I have posted to the forums) and they all behave correctly. It only happens with my production system. So the problem must lie between the keyboard and the chair, but I can't seem to figure out what I am doing wrong.

Here is my esb definition:

<?xml version="1.0"?>
<jbossesb parameterReloadSecs="5000"
     xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd">
     <providers>
          <schedule-provider name="scheduler">
               <property name="org.quartz.scheduler.wrapJobExecutionInUserTransaction" value="false"/>
               <simple-schedule scheduleid="rlog-trigger" frequency="60"/>
          </schedule-provider>
          
     </providers>
     <services>
          <service category="RlogActions" description="Extracts messages from DB" invmScope="GLOBAL" invmTransacted="false" name="ExtractorActions">
               <property name="maxThreads" value="1" />
               <listeners>
                    <scheduled-listener name="rlog-extractor-listener"
                         scheduleidref="rlog-trigger"
                         event-processor="za.co.fnb.corp.cit.cash.rlog2sbsvr.actions.RlogScheduler" />
               </listeners>
               <actions mep="OneWay">
                    <action class="za.co.fnb.corp.cit.cash.rlog2sbsvr.actions.RlogExtractorAction" name="RlogExtractAction" process="process">
                         <property name="skipFirst" value="2"/>
                    </action>
               </actions>
          </service>
          
          <service category="RlogActions" description="Processes RLog messages in the message store"
               invmScope="GLOBAL" invmTransacted="false" name="ProcessorAction">
               <property name="maxThreads" value="1" />
               <listeners>
                    <scheduled-listener name="rlog-processor-listener"
                         scheduleidref="rlog-trigger"
                         event-processor="za.co.fnb.corp.cit.cash.rlog2sbsvr.actions.RlogScheduler" />
               </listeners>
               <actions mep="OneWay">
                    <action class="za.co.fnb.corp.cit.cash.rlog2sbsvr.actions.RlogProcessorAction" name="RlogProcessAction" process="process">
                         <property name="skipFirst" value="2"/>
                         <property name="maxProcessCalls" value="100"/>
                    </action>
               </actions>
          </service> 
     </services>
</jbossesb>

The admin console confirms this:

Anything else I could be doing wrong that you know of?

[tfennelly]

So in the case you identified there, 2 instances of the RlogProcessorAction will be in existance for each of those services because each service has 2 message aware listeners (invm and scheduled) i.e. an action pipeline instance is created for each message aware listener, with 1 instance of each action on each pipeline.

What are you expecting to see?  How are you verifying that multiple instances are being created?

[quintona]

I was under the impression that a single instance of the pipeline existed regardless of how many listeners there were. I thought the action was basically a singleton.

It was verified by simply logging the number of calls into the constructor of each action.

Ok, so that was a lack of understanding on my side, thanks.

[edx]

Hello,

my observation of the number of action instances is that for the each instance of the listener (thread) there is an allocation of separate action pipeline.

The action is not a singleton - it does not serve the execution context for the each listener thread.

Edward