Announcement Announcement Module
No announcement yet.
Lazy init and activate/deactivate of jms:inbound-gateway Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Lazy init and activate/deactivate of jms:inbound-gateway

    Looking at the javadoc of the SimpleMessageListenerContainer its seems possible to activate/deactivate the MessageListenerContainer using the doStop/doStart methods.

    I presume the jms:inbound-gateway uses some kind of MessageListenerContainer under the hood. So is it possible to activate/deactivate the jms:inbound-gateway.

    This would be nice because at some point you would like to stop your application from accepting messages for a certain amount of time.

    With the lazy init, the jms:inbound-gateway wouldn't start accepting messages right away, but would wait for until its doStart has been called. For example I would like to read multiple messages from a file and store them into memory. This data is needed to treat the messages read from a queue. But for the reading from the file I would also like to use spring integration components. This could be solved by using two seperate application contexts and loading them at a different point in time, but this doesn't look like a decent solution.

  • #2
    JmsMessageDrivenEndpoint does implement Spring's Lifecycle interface and invokes start/stop on the underlying container. Therefore, if you get a handle to the endpoint (either with a DI "ref" or runtime lookup using its "id" value as bean name), then you can invoke start/stop on that.

    Hope that helps.


    • #3
      Yes, it helps a lot that the start/stop on the underlying container is called.
      It solves all my problems but then one that occurs when starting the application.

      However if you get the handle to the endpoint preferably using DI into an Orchestrator the following problems occurs at start up : (Correct me if I'm wrong about this)

      Phase 1 : Spring will set up all the dependencies,
      Phase 2 : Spring will call the init method for all the beans.
      However it will call the init method of the JmsMessageDrivenEndpoint before calling the init method of the Orchestrator, were the stop method of the JmsMessageDrivenEndpoint will be called.
      Then the file will be read and after this the Orchestrator will call the start method of the JmsMessageDrivenEndpoint.

      This way there is a short amount of time the JmsMessageDrivenEndpoint will read from the queues although it isn't supposed to.
      I know you can right your own BeanPostProcessor, but I don't think this can solve this problem.
      Therefore my question about the lazy init, that creates the JmsMessageDrivenEndpoint, but doesn't start it yet. Is such a thing possible?


      • #4
        Did you try setting the 'auto-startup' attribute to false in the endpoint definition?


        • #5
          No I didn't.
          So next times all study the various parameters that can be set, before asking any stupid and unnecessary question.


          • #6
            bassegio -- don't be so hard on yourself.. someone else will learn from this.. although self-deprecation is the best type of humor.