• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Tim Cooke
  • Devaka Cooray
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
  • Mikalai Zaikin
Bartenders:
  • Carey Brown
  • Roland Mueller

Disabling JMS Topic Subscription via property

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a Spring application deployed in an EAR on WLS 10.3. The same EAR is deployed in a couple of different enclaves/environments, and there are a few things that differ between the installations. So I have a small properties file that's read and processed by an initialization bean to accommodate these differences (mostly webservice endpoints).

One of the things this application does is subscribe to a JMS topic on a remote server. However, I want to be able to enable or disable this subscription when I restart the application. The remote publisher may publish over a thousand messages per minute, so I don't just want to return prematurely from the onMessage() method. I want to completely disable the connection/subscription to the topic.

I thought if I could get the container bean reference in the initialization bean, I could shut it down that way. However, "<jms:listener-container" doesn't have an id attribute.

How can I enable/disable a JMS connection to a topic on application start up; preferably via an initialization bean?
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry, I am a little confused. But I have a motto, where if something seems difficult to figure out, or you have to do some odd fix to make something work, then there is something missing in the design or thought approach.

My guess here would be to have different Spring configurations for the different environments. And if you separate your JMS configuration from all you other configurations, then all the other configuration files stay the same, and the only different is the config file for JMS. In most cases your build process can do this automatically for you.

Mark
 
John Bize
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I apologize for the confusion. There are other factors and constraints involved. Rebuilding and packaging the application with the enabled or disabled JMS listener is how I am doing it now. It's disruptive and impractical in my environment/network. I want to change that. My preference would be to simply change the Boolean state of a property in a properties file and restart. I'm open to other suggestions too, as long as I don't have to rebuild and deploy the EAR to make the change.

I suppose the bottom line is: How can I enable/disable a JMS listener connection to a topic programatically?

Thanks.
 
John Bize
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, I stumbled into this... Although the "<jms:listener-container" doesn't have an id attribute, the embedded "<jms:listener" does. So I injected the reference into my initialization bean, checked the class name, and (surprise!) it's a (the) DefaultMessageListenerContainer. Not what I expected, but what I wanted.

So now, should I issue a .shutdown(), .stop(), or .destroy() to properly disable the listener and connection?
 
Ranch Hand
Posts: 597
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jhon,
I don't think the way you are trying to do will work. By the time your initialzing method, is called the bean is already created by container and references are injected. So it has already subscribed to topic.
 
John Bize
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Sandeep.

There's actually a fairly significant delay before the messages start to come in. But even if there wasn't, it wouldn't really affect this particular application. It's more important that I shut it down as soon as is practicable.

That said, and with a reference to my DefaultMessageListenerContainer, (directly or via sub-class)...

What is the proper (safe and effective) way to terminate the subscription?

Thanks.
 
Sandeep Awasthi
Ranch Hand
Posts: 597
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am not sure but just suggesting.

Try to get reference to javax.jms.Connection and call stop method on it on the condition in which you do not want to receive messages.

I have never tried such things. But you may have to do some research.
 
John Bize
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well as of right now, I have the message listener container reference as an AbstractJmsListeningContainer, and I call shutdown(), stop(), and destroy() on it.

It seems to behave correctly, but I don't know if it really is.

What's the correct way to safely, reliably, and effectively shut it down (without hanging, blocking, crashing, throwing exceptions, etc.)?

Thanks.
 
Don't touch me. And dont' touch this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic