Random "dispatcher has no subscribers" exception with Spring Batch

[akaabal]

We currently have a spring batch application in production that is experiencing MessageDeliveryException randomly. The exception is occurring in an item processor that uses a JMS outbound gateway.

Here's the relevant config:

     <si:channel id="requestChannel"/>

    <jms:outbound-gateway id="outboundGateway" request-channel="requestChannel"
                          connection-factory="connectionFactory"
                          request-destination="requestQueue"
                          reply-channel="responseChannel"
                          receive-timeout="1200000" />

    <si:channel id="responseChannel"/>

    <bean id="changesvcRequestQueue" class="com.ibm.mq.jms.MQQueue">
        <constructor-arg index="0" value="QUEUE.NAME.HERE"/>
    </bean>

    <si:gateway id="requestGateway" default-request-channel="requestChannel"
        default-reply-channel="responseChannel"
        service-interface="o.o.t.s.MessagingServiceGateway" />

I have to add that the item processor that uses the gateway is set up to have a scope of "step" and it is a delegate in a composite item processor.

<bean id="processor4" class="o.o.t.p.ProcessorFour" scope="step">
    <property name="gateway" ref="requestGateway"/>
</bean>
<bean id="compositeProcessor" class="org.springframework.batch.item.support.CompositeItemProcessor" scope="step">
    <property name="delegates">
        <list>
            <ref bean="processorOne"/>
            <ref bean="processorTwo"/>
            <ref bean="processorThree"/>
            <ref bean="processorFour"/>
        </list>
    </property>
</bean>

Another developer suggested that the speed of processing may be causing the item processor to do its work before the gateway has finished all the setup/initialization it needs to do. Is this possible? Anyone else experienced this? Ideas? Help!

[Gary Russell]

Sounds like something is starting to execute before the context is fully initialized. In general, this shouldn't happen unless you initialize some processing in a bean lifecycle method, such as afterPropertiesSet(). This is too early, but you might get away with it sometimes, even most of the time.

The fact that your ItemProcessor is step scope won't make a difference because the gateway is singleton scope. However, the gateway will be injected before the context is fully baked. The channel.subscribe() occurs when the outboundGateway is start()ed during the context.refresh().

You could inject an EventDrivenConsumer (the outboundGateway) and wait until it's isRunning() method returns true, but that is a little fragile; it would be better to fix the root cause and don't start processing until the context is fully initialized.

[akaabal]

Gary, thanks for responding.

It makes sense what you're saying... however, I don't quite follow how it's possible for the context not to be fully initialized if this processor is used in the fourth (or later) step of our spring batch flow.

[Gary Russell]

I agree it does sound strange, but I can assure you that the only way you'll get a dispatcher has no subscribers (on requestChannel) if you call the gateway before the outboundGateway is start()ed.

If you can reproduce with debug logging (for org.springframework), you'll see all the bean lifecycle stuff being logged.

Are you sure it's this channel that's getting the error? If you run with 2.1.3, the 'dispatcher has no subscribers' message now includes the channel name.

[akaabal]

We use spring-batch-admin in this project and now that I've uped the version of spring-integration, it's complainging about the file-context.xml resource (because of the schema version)...

[Gary Russell]

We need to put out a new version of spring-batch-admin without any versions in the integration schemas.

There's an open JIRA to move batch admin to SI 2.1...

https://jira.springsource.org/browse/BATCHADM-131

Schemas for the unit tests have been fixed in the master branch (1.2.2.BUILD-SNAPSHOT), but I see there are still some 2.0 schema references in some integration tests.