Announcement Announcement Module
Collapse
No announcement yet.
DefaultMessageListenerContainer reconnecting at startup Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • DefaultMessageListenerContainer reconnecting at startup

    To ensure the application can recover when the JMS server down at startup, my application code will establish a JMS connection before attempting to load the DefaultMessageListenerContainer from the spring context. I have set lazy-init to true on all of the beans including the AbstractJNDI queue bean.

    However, when I start my application and the JMS server is down, I get errors since the application context trys to resolve the bean ref to the queue and fails because the JMS server is down.

    Does the fact that I have a bean ref to the JNDI queue within the container force it to load even if I have every bean set to lazy initialize?

    Perhaps there is a better way to solve this problem of a JMS server not being available on startup?
    Last edited by bhusted; Oct 19th, 2007, 11:03 AM.

  • #2
    have you tried setting the property 'recoveryInterval' for DMLC ? This will cause DMLC to keep trying to resolve Connections/Destinations at that interval.

    Comment


    • #3
      It seems that you injected you container to another bean which is not lazily instantiated. In this case 'lazy-init' attribute is ignored and container object is created at application context initialization. You can check this easily by writing a simple application with the only bean of class DML with 'lazy-init' attribute set to true. It must not be created at context startup initialization.

      Comment

      Working...
      X