Spring Integration
  1. Spring Integration
  2. INT-1498

jms:message-driven-channel-adapter and startup ("Dispatcher has no subscribers.") with Spring core 3.0

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.0.4
    • Fix Version/s: 1.0.5
    • Component/s: Core
    • Labels:
      None
    • Environment:
      Windows

      Description

      Spring Integration 1.0.4 does not respect startup lifecycle when using Spring Core 3.0.
      This might make jms:message-driver-adapter to consume a message before all other beans are started and then throw a org.springframework.integration.message.MessageDeliveryException: Dispatcher has no subscribers.

      Debug messages from JMS sample running with Spring Core 2.5.6. Note that jmsin is the last one started.

      INFO : org.springframework.integration.config.xml.DefaultConfiguringBeanFactoryPostProcessor - No bean named 'errorChannel' has been explicitly defined. Therefore, a default PublishSubscribeChannel will be created.
      INFO : org.springframework.integration.config.xml.DefaultConfiguringBeanFactoryPostProcessor - No bean named 'taskScheduler' has been explicitly defined. Therefore, a default SimpleTaskScheduler will be created.
      INFO : org.springframework.integration.endpoint.EventDrivenConsumer - started colourMover
      INFO : org.springframework.integration.endpoint.EventDrivenConsumer - started stdout
      INFO : org.springframework.integration.jms.JmsMessageDrivenEndpoint - started jmsin
      INFO : org.springframework.integration.endpoint.EventDrivenConsumer - started org.springframework.integration.endpoint.EventDrivenConsumer#0
      INFO : org.springframework.integration.scheduling.SimpleTaskScheduler - started org.springframework.integration.scheduling.SimpleTaskScheduler@bb0d0d
      

      But when you switch to Spring Core 3.0.X jmsin is the first one started.

      INFO : org.springframework.integration.config.xml.DefaultConfiguringBeanFactoryPostProcessor - No bean named 'errorChannel' has been explicitly defined. Therefore, a default PublishSubscribeChannel will be created.
      INFO : org.springframework.integration.config.xml.DefaultConfiguringBeanFactoryPostProcessor - No bean named 'taskScheduler' has been explicitly defined. Therefore, a default SimpleTaskScheduler will be created.
      INFO : org.springframework.integration.jms.JmsMessageDrivenEndpoint - started jmsin
      INFO : org.springframework.integration.endpoint.EventDrivenConsumer - started colourMover
      INFO : org.springframework.integration.endpoint.EventDrivenConsumer - started stdout
      INFO : org.springframework.integration.endpoint.EventDrivenConsumer - started org.springframework.integration.endpoint.EventDrivenConsumer#0
      INFO : org.springframework.integration.scheduling.SimpleTaskScheduler - started org.springframework.integration.scheduling.SimpleTaskScheduler@64ab4d
      

      Configuration file used

      <?xml version="1.0" encoding="UTF-8"?>
      <beans:beans xmlns="http://www.springframework.org/schema/integration"
      	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:beans="http://www.springframework.org/schema/beans"
      	xmlns:jms="http://www.springframework.org/schema/integration/jms"
      	xmlns:stream="http://www.springframework.org/schema/integration/stream"
      	xmlns:file="http://www.springframework.org/schema/integration/file"
      	xsi:schemaLocation="http://www.springframework.org/schema/beans
      			http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
      			http://www.springframework.org/schema/integration
      			http://www.springframework.org/schema/integration/spring-integration-1.0.xsd
      			http://www.springframework.org/schema/integration/jms
      			http://www.springframework.org/schema/integration/jms/spring-integration-jms-1.0.xsd
      			http://www.springframework.org/schema/integration/stream
      			http://www.springframework.org/schema/integration/stream/spring-integration-stream-1.0.xsd
      			http://www.springframework.org/schema/integration/file
                  http://www.springframework.org/schema/integration/file/spring-integration-file-1.0.xsd">
      
      	<beans:bean id="containerColourIn" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
      		<beans:property name="autoStartup" value="true" />
      		<beans:property name="connectionFactory" ref="connectionFactory" />
      		<beans:property name="destination" ref="requestQueue" />
      	</beans:bean>
      
      	<jms:message-driven-channel-adapter
      		id="jmsin" auto-startup="true" channel="jmsinToStdoutChannel" container="containerColourIn"/>
      
      	<file:outbound-gateway id="colourMover"
      		request-channel="jmsinToStdoutChannel" reply-channel="jmsinToStdoutChannelReply"
      		directory="file:C:/TEMP/springtest" delete-source-files="true" />
      
      	<channel id="jmsinToStdoutChannelReply"/>
      
      	<stream:stdout-channel-adapter id="stdout"
      		channel="jmsinToStdoutChannelReply" append-newline="true" />
      
      </beans:beans>
      

        Activity

        Hide
        Mark Fisher added a comment -

        The reason for this is that Spring 3.0 adds a SmartLifecycle interface containing an 'autoStartup' property such that any bean implementing that interface can be started after the context and its beans are fully initialized. Spring 2.5.6 does not have that interface and so components that need to have "auto startup" capabilities would typically start within the initialization phase.

        We cannot make any component within Spring Integration 1.0.x implement the SmartLifecycle interface since that was introduced in Spring 3.0, and the minimum required version for 1.0.5 is still 2.5.6.

        The best way to overcome this startup order issue is to upgrade to Spring Integration 2.0.x. There, the SmartLifecycle is being implemented.

        Jakob, it's been a while since you reported this issue; are you by any chance able to upgrade or already upgraded to Spring Integration 2.0.x?

        Show
        Mark Fisher added a comment - The reason for this is that Spring 3.0 adds a SmartLifecycle interface containing an 'autoStartup' property such that any bean implementing that interface can be started after the context and its beans are fully initialized. Spring 2.5.6 does not have that interface and so components that need to have "auto startup" capabilities would typically start within the initialization phase. We cannot make any component within Spring Integration 1.0.x implement the SmartLifecycle interface since that was introduced in Spring 3.0, and the minimum required version for 1.0.5 is still 2.5.6. The best way to overcome this startup order issue is to upgrade to Spring Integration 2.0.x. There, the SmartLifecycle is being implemented. Jakob, it's been a while since you reported this issue; are you by any chance able to upgrade or already upgraded to Spring Integration 2.0.x?
        Hide
        Jakob Ericsson added a comment -

        We will upgrade as soon as possible.

        Right now we solved this problem by setting the listeners autoStartup=false and then have our own SmartLifecycle bean to start them.

        You can close this issue.

        Show
        Jakob Ericsson added a comment - We will upgrade as soon as possible. Right now we solved this problem by setting the listeners autoStartup=false and then have our own SmartLifecycle bean to start them. You can close this issue.
        Hide
        Mark Fisher added a comment -

        Thank you. That was exactly what I planned to recommend as an interim workaround.

        In any case, 1.0.5 should be out shortly (this week most likely).

        Show
        Mark Fisher added a comment - Thank you. That was exactly what I planned to recommend as an interim workaround. In any case, 1.0.5 should be out shortly (this week most likely).
        Hide
        Mark Fisher added a comment -

        The only true solution to this is to upgrade to Spring Integration 2.0.x where the Spring Integration code itself conforms to the new, improved lifecycle model. Unlike version 1.0.x, the 2.0.x code base officially supports (requires, actually) Spring 3.0.x.

        In the meantime, the workaround described within the comments here is recommended for anyone using Spring Integration 1.0.x with Spring 3.0.x.

        Show
        Mark Fisher added a comment - The only true solution to this is to upgrade to Spring Integration 2.0.x where the Spring Integration code itself conforms to the new, improved lifecycle model. Unlike version 1.0.x, the 2.0.x code base officially supports (requires, actually) Spring 3.0.x. In the meantime, the workaround described within the comments here is recommended for anyone using Spring Integration 1.0.x with Spring 3.0.x.

          People

          • Assignee:
            Mark Fisher
            Reporter:
            Jakob Ericsson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: