Oct 19th, 2007, 11:00 AM
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 at 11:03 AM.
Nov 1st, 2007, 03:38 PM
have you tried setting the property 'recoveryInterval' for DMLC ? This will cause DMLC to keep trying to resolve Connections/Destinations at that interval.
Nov 2nd, 2007, 02:21 AM
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.