Technorati Tags:
ALSB,
WebLogic,
JMS
Overview
Over the past few months I have been implementing ALSB 3.0 along-side a WebLogic 8.1 environment which has been running for around 5 years, originally starting on WLS 7.0.
When I went through performance tuning and deployment of MDB’s in WLS8.1, something I paid attention to was consumers on the queue, as the wrong amount could have negative effects on performance. More consumers also means more JMS threads for the JVM to worry about managing.
I ended up with some MDB’s only having a single consumer, and some having 4 or 5. This meant that I could meet the performance expectations without killing the system – or the destination system if the MDB made a call to another part of the infrastructure, say LPD or E-Mail, even SOAP.
Where do you configure consumers in ALSB 3.0?
Learning about how ALSB 3.0 works has been very “on the job” for the past few months. WLS10 was also a new app server to get used to, and it’s quite different to WLS8.1, I simply haven’t had the time to learn WLS10 with everything else that’s going on.
I’ve probably learnt parts of ALSB the hard way – why you really should use the domain configuration wizard when creating an ALSB cluster rather than do it manually for example!!
Anyway, back to consumers.
When you initially create a JMS proxy service and target it to a queue, it will deploy 16 consumers by default. This may be Ok for some applications, but I wanted a way to reduce that and therefore reduce the risk of all 16 consumers going active at once.
What I was hoping to find was an equivalent to the <max-beans-in-pool> deployment descriptor setting or an equivalent somewhere, but after extensive searching I didn’t find anything.
I found references to work managers, which talked about setting thresholds on max threads etc, but to me, coming from a WLS 8.1 environment, thread pools were something you used to assign a web app or other process to, so that you didn’t run out of threads in the default thread pool. They weren’t used for restricting consumers on a JMS queue. They could be I suppose, but then you’d end up with pending requests on the thread pool as you would have more consumers than available threads which isn’t ideal.
After some more reading and actually trying it out, it seems that work managers really are the way to go with controlling consumers on JMS proxy services.
Creating a work manager.
Basically, what you do – on the ALSB environment, using the WebLogic console create a work manager. When asked – a standard work manager will do.
Once you’ve gone through all the screens, you can then select the work manager, and then add a “Maximum Threads Constraint”.
Now, you need to edit the proxy service in ALSB, and assign a dispatch-policy, which is the work manager you created above, and all being well, this should appear in the drop-down list. If it doesn’t, something has gone wrong when it was created.
That’s all there is too it, you now have a reduced number of consumers on the JMS destination.
There is a very nice article here OSB and Thread Pools together with documentation here OSB and Thread Pools Documentation which explains this, and also includes nicer diagrams than mine!
Hope this post is remotely useful!