| Author |
Message
|
| Monk |
 Posted: Thu Apr 16, 2009 10:53 am Post subject: Top 5 most painful things in MQ. |
 |
|
Master
Joined: 21 Apr 2007
Posts: 282
|
Hi All,
I would like to know what are top 5 most painful things in MQ.
for e.g it could be in administration, monitoring, and just about anything to do with MQ.
Poobah: I posted it here becoz many people come to this thread of the forum.
So a big request is , if you could copy this to all threads in the site , it would be great.
Thanks for your answers.
_________________
Thimk |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Thu Apr 16, 2009 11:58 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
1. Badly designed applications.
2. Badly coded applications.
3. The statement 'MQ lost my message'
4. The statement 'MQ isn't working'
5. The question 'What will MQ do with my message if.....' |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 16, 2009 12:00 pm Post subject: Re: Top 5 most painful things in MQ. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Monk wrote: |
I would like to know what are top 5 most painful things in MQ.
for e.g it could be in administration, monitoring, and just about anything to do with MQ. |
Does answering dim question on this forum count? 
My top 5:
- hearing that "MQ has lost my message" from the application staff
- explaining that assured delivery means that delivery is assured to management (and thus delivery reports, replies, audit, etc are unnecessary)
- explaining that neither MsgId nor CorrelId is a string, and should be left to the queue manager
- finding out what's causing the 2059 / retrying channel this time
- applying security to a newly defined queue manager
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 16, 2009 12:01 pm Post subject: Re: Top 5 most painful things in MQ. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Monk wrote: |
Poobah: I posted it here becoz many people come to this thread of the forum.
So a big request is , if you could copy this to all threads in the site , it would be great.
|
We don't allow duplicated posts here, but I've moved it to a better section.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Apr 16, 2009 1:57 pm Post subject: Re: Top 5 most painful things in MQ. |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| Does answering dim question on this forum count? |
Yet again my master is too fast for me...
1. Not being allowed to do proper solution design, and generally any solution design.
2. The amount of work, and rework, caused by 1. above.
3. Explaining that putting an application userid in the mqm group may 'make it work' but is really, really not a good idea.
4. Lack of detail in SSL-related error messages - why can't it be like WAS?
5. Developers that insert their own error messages rather than cascading the MQRC.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 16, 2009 2:18 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
- Explaining that persistence is an application responsability, giving them my suggestion and seeing that they don't care...
- Having somebody with good intentions create another server to share the load in the cluster and forget to change the cluster channels before loading the build script to the qmgr.
- hearing it's the fault of MQ, yet nobody has even looked to prove it is neither the network nor disk related.
- being asked to do a stress test at a level that hits less than 5% cpu on the MQ Unix box...
- last but not least ;"Where's my message? I can't find it so it's gotta be MQ's fault!"
_________________
MQ & Broker admin
Last edited by fjb_saper on Thu Apr 16, 2009 8:50 pm; edited 1 time in total |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Thu Apr 16, 2009 3:22 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
1. Application team expects - tell me at what date/what time my app put the message onto the queue and tell me how long the msg was sitting on the queue. Expecting DB features in MQ.
2. App is not pulling off the messages from queues and file system got filled up. All are persistent messages and the MQ goes down and never comes up until there is enough disk space. When you get paged for MQ error in the middle of the night and dont know which Unix admin to get hold of and he asks for Manager to approve. Dont know whether we can wake up our manager in the middle of the night.
3. The app raising an issue on monday saying on friday I had an MQ issue and the system was too slow. On monday when I look into the FDCs..nothing wrong is there and in the QMgr errors dont see anything about friday as they overwrite during the weekend test.
4. App doesn't know what API calls they have to use and how to use and ask the admins to help with their code and MQ admin is not that good with the coding and search the forums and ask for somebody's help as it is his issue.
5. Clustering and security - When the app wants to specify the QMgr along with cluster queue name(remote queue) in its MQOD, the app needs to provide the permissions to S.C.T.Q or should be member of mqm group with which our management not going to accept and you need to convince the app which is not going to work.
thanks. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 16, 2009 3:46 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Sam Uppu wrote: |
| 5. Clustering and security - When the app wants to specify the QMgr along with cluster queue name(remote queue) in its MQOD, the app needs to provide the permissions to S.C.T.Q or should be member of mqm group with which our management not going to accept and you need to convince the app which is not going to work. |
Cluster alias. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 16, 2009 3:52 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqjeff wrote: |
| Sam Uppu wrote: |
| 5. Clustering and security - When the app wants to specify the QMgr along with cluster queue name(remote queue) in its MQOD, the app needs to provide the permissions to S.C.T.Q or should be member of mqm group with which our management not going to accept and you need to convince the app which is not going to work. |
Cluster alias. |
If the app has full access to the S.C.T.Q. it can send any message to any queue manager in the the cluster.
If you use a cluster alias, you restrict that app to sending any message to just that 1 other QM. Slightly better I suppose. Not much though. Tagging the CLUSRCVR with an MCAUSER with very limited rights can help further restrict the hole, but its still a big hole. If you are replying to a ReplyToQ / ReplyToQM in a cluster, true security becomes, I guess, impossible?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Thu Apr 16, 2009 4:18 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| Quote: |
| If you are replying to a ReplyToQ / ReplyToQM in a cluster, true security becomes, I guess, impossible? |
I meant this.
Thanks. |
|
| Back to top |
|
|
| Monk |
| Posted: Thu Apr 16, 2009 8:59 pm Post subject: |
|
|
Master
Joined: 21 Apr 2007
Posts: 282
|
Good list guys,
thanks..
_________________
Thimk |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Fri Apr 17, 2009 6:11 am Post subject: My top 5 |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
1. Client Application says, MQ Lost the Messages and we are getting timeout in case of reply, and they don't check/contact the Target application is up and running or not. They bang on MQ.
2. No. of connections rise on the channel for an application and once the threshold reaches they are being denied for more connections. They don't check in their code whether they are having code to close the earlier requested connections or not.
3. Hear: MQ is not behaving properly after installing a fixpack to remove the bug(s) that was causing problem(s) earlier. Earlier and now after fix pack being installed applications are still not satisfied.
4. Some mis match in the certificates being mentioned by the application for connection over SSL channel. And they are getting something else interms of error/exception then what they should. So then look into MQ logs / security logs to check what and where the issue is.
5. Hear: Why the MQ can't do the things that Java/.Net can do. Its hard sometimes to tell them the diff. between front/back end and middleware components.
But MQ Rules. |
|
| Back to top |
|
|
|
|
