By default, the DMLC will start up automatically when the Spring application context is started. This is controlled by the autoStartup property in the AbstractJmsListeningContainer set to true. There's no need to start up the listeners as you mentioned because they get invoked each time a message arrives in the DMLC.
Which message listener interface does your TCDataSubscriber bean implement? For more info, see the Spring Reference Doc's section named Receiving a message.
My TCDataSubsciber implements javax.jms.MessageListener.
When I stop JMS server application throws exception saying Destination Unreachable. When I start JMS server again I can not see the DMLC created threads running.
How to test if DMLC tries to reconnect ?
Well the error states that 'Client id, TCAnsPaperSubscriber471, is in use.' So it seems like a client id is being used twice. The error detail is also telling you where that client id is being used:
"The JNDI name weblogic.jms.connection.clientid.TCAnsPaperSubscriber471 was found, and was bound to an object of type weblogic.jms.frontend.FEClientIDSingularAggregatable : FEClientIDSingularAggregatable(SingularAggregatable(<6176547454817656908.1>:302):TCAnsPaperSubscriber471)"
When I looked up into my JMS server, I found that there is active connection for TCAnsPaperSubscriber471. When I destroy connection and then start my weblogic server where I deployed my application, I do not get "Client id in use" error. When Application gets up I can see active connection for TCAnsPaperSubscriber471. If I restart weblogic server again without destroying connection then I get the same error "Client Id in use".
Is this related to autoStartup property being false for DMLC ? If yes how can I destroy connection when my application/server goes down?
If the JndiObjectFactoryBean and the DMLC are both not marked to not start up by default, then I'm not sure where the connection is coming from. If I had this problem, I would grab a thread dump from the app while it's running so that I could locate the stack trace containing the JMS Connection object. This might help you understand where the connection is originating.