|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Connection Retries: What Advice to Give Developers? |
« View previous topic :: View next topic » |
Author |
Message
|
SAFraser |
Posted: Tue Jan 10, 2006 8:56 am Post subject: Connection Retries: What Advice to Give Developers? |
|
|
 Shaman
Joined: 22 Oct 2003 Posts: 742 Location: Austin, Texas, USA
|
As many of you know, I am an MQ admin but not a developer. I do generally know enough about MQ programming to help a developer troubleshoot code and to understand the application architecture.
We have a new project that will be starting soon. I want to be sure that connection retries are included in the code because their queue manager will eventually be a member of a high-availability MQ cluster. The app will be accessing MQ from two servers, one using the MQ Perl module and the other using JMS (app running on WAS). On the WAS server, they will listen for messages using MDBs. They will use connection pooling on WAS (and maybe in their app, too?). The developers may or may not be fully familiar with MQ.
Here's my dilemma. I would like to say "be sure your code is HA-ready" and leave it at that. But should I be asking them other questions? Like, are you linking JMS exceptions to MQ reason codes? Are you trapping and handling MQ reason codes? How does your app know if it has lost its connection? Are you closing/disconnecting/connecting periodically? What is your algorithm for connection retries?
If they give me answers to those questions, I'm not confident I can evaluate their answers. I've searched here, I've googled the web, I've poked through MQ manuals. Yet, I think I can still be flummoxed by a fast-talking developer on this topic.
If you've stuck with me to this point, you know I'm really presenting two questions:
1. Big picture: what is my responsibility to provide detailed technical coding advice?
2. Specifically: what additional technical information do I need to assure this code gets written correctly? what should I study? what else should I ask of them?
As always, I will appreciate your thoughts and gentle replies.
Shirley |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jan 10, 2006 9:18 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
It shouldn't be your responsibility to provide any coding advice.
That said, you should provide them the answers to any specific questions they ask, and provide them directions to look into to make sure that they can properly troubleshoot their application - like reporting the linked exception in JMS code (it's not a linkage they have to make, just one they have to use).
And you should make them aware that they will be running in a HA environment and that it will be perfectly normal in lots of cases for their MQ connection to drop because the QM is being failed over. And so they should evaluate their own business requirements and determine how that should be handled - do the Java team want their App Server restarted? Do they want to retry connections until the pool gets refreshed and new connections are available - etc.
And then you should make sure that a test of the HA failover is included in their test plan. Or at least a simulated test - kill the MQ listener for five minutes or something.
It might be a good idea to spend some additional time monitoring their development qmgrs during their cycle, too, if you can. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Jan 10, 2006 10:22 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
as Jeff said, test, test, test! And make sure both the developers and the people that will get paged in production are involved (that's why the developers code sloppy - they ain't gettin' paged at 2 AM!)
I have my DEV QMs scripted to restart every night. This way the developers see what its like to lose the connection every night. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|