|
Replies:
0
|
|
|
|
|
|
|
JMS In Web Services -- lessons learned.
Posted:
Oct 23, 2008 3:11 PM
|
|
|
I've had to undergo a process of adapting a web app written for another jms implementation to glassfish. As we were planning to cluster our brokers, I did all my work with glassfish jms set to REMOTE, though LOCAL has the same issues discussed below. I ran the imqbrokerd on another machine. Here are the lessons I learned that most (not all) the internet docs and articles I read neglected to tell me:
1. Property imqConfiguredClientID in your JMS Resource should be set to avoid the Illegal ClientID = "" errors. I also set imqEnableSharedClientID to true, though I dunno if that is necessary.
2. One active Session per connection. No exceptions.
3. The glassfish JMS Client will tie the Connections you get from the pool to your THREAD -- not to a weakreference. If your http call happens to initialize a static class that grabs a connection and establishes a listener, it will ALL go away as soon as your http call thread dies. Context Listeners are a great place for establishing longterm JMS message consumers.
4.If you are initializing jms connections in a context listener, don't try to get connections via jndi by connecting directly to your port 3700 via iiop://. It will hose Glassfish altogether due to an inability to even connect. If you do hose Glassfish, learning to manually modify your domain.xml is important -- just set those offending context listening web apps to enabled=false! The correct was to get your jndi context is with a simple context=new InitialContext()
5.As an addendum to #3 above, do not keep those jms connections you grab in a static reference for use later. Grab a new one every time -- that's what the pool is for! An exception to this would be the connections for message consumers, which need to always created from a persisting thread (either one you make yourself, or the one glassfish uses to call initializeContext(..)
- Bo
|
|
|
|
java.net RSS
