| Author |
Message
|
| John89011 |
 Posted: Wed Oct 28, 2009 1:13 pm Post subject: message restriction |
 |
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
Is it possible to restrict message types on a WMQ level?
Reason is, we received a jms message and our app can not handle jms messages so it hosed the process. We can make code changes to discard the messages or get it on DLQ that's not a problem. I was just wondering if there was something on the WMQ level like a parimiter to be set/changed?
Thanks! |
|
| Back to top |
|
 |
| John89011 |
| Posted: Wed Oct 28, 2009 1:14 pm Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
| Sorry forgot to include that this is 6.0.2.4 on Solaris |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 28, 2009 1:50 pm Post subject: Re: message restriction |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| John89011 wrote: |
| Reason is, we received a jms message and our app can not handle jms messages so it hosed the process. |
There's no distinction in WMQ about message type; it can't see the process that put the message. The only exception to this rule is if some conditions are met WMQ will convert the message into the correct code page.
| John89011 wrote: |
| We can make code changes to discard the messages |
That's a bit harsh - what happens if the jms message contains valid business content? You have a problem earlier on in your development process if this app is sending messages that can't be processed, or hasn't been given it's own queue to send to.
| John89011 wrote: |
| or get it on DLQ that's not a problem. |
That's not a good idea. The DLQ has a specific use (the holding of undeliverable messages) and this message is delivered. It clearly can't be processed, but the DLQ is not the right place for it. If you insist on using it, make sure your app adds the correct DLH or you'll have problems processing them.
If you prefer something a bit more mainstream, you could use the facilties WMQ provides for this situation and define a backout queue where these messages can be placed when rejected by the app.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Oct 28, 2009 4:07 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| reason is, we received a jms message and our app can not handle jms messages so it hosed the process. |
What do you do in other applications when you have bad (defective) data input?
Your best choices are 1) fix the requesting app so it doesn't send defective messages; or 2) fix the replying application so that it processes defective messages.
As pointed out here, a message is a message.
Exactly what do you mean by hosed the process? Be specific. Did the app abend? Did it issue any ReasonCode? Anything in the MQ error logs? Was it killed by the o/s?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 28, 2009 6:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Is your app expecting JMS messages or MQ messages?
Have you looked into changing the JNDI of the sending app and set the destinations (queues) up for type MQ and not JMS.
Think uri ?targetClient=1 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| John89011 |
| Posted: Thu Oct 29, 2009 4:31 am Post subject: Re: message restriction |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
| Vitor wrote: |
| John89011 wrote: |
| Reason is, we received a jms message and our app can not handle jms messages so it hosed the process. |
There's no distinction in WMQ about message type; it can't see the process that put the message. The only exception to this rule is if some conditions are met WMQ will convert the message into the correct code page.
| John89011 wrote: |
| We can make code changes to discard the messages |
| Quote: |
| That's a bit harsh - what happens if the jms message contains valid business content? |
In this case it did not, however even if it did, the business goals have been clearly communicated to these folks.
| John89011 wrote: |
| or get it on DLQ that's not a problem. |
That's not a good idea. The DLQ has a specific use (the holding of undeliverable messages) and this message is delivered. It clearly can't be processed, but the DLQ is not the right place for it. If you insist on using it, make sure your app adds the correct DLH or you'll have problems processing them.
| Quote: |
| If you prefer something a bit more mainstream, you could use the facilties WMQ provides for this situation and define a backout queue where these messages can be placed when rejected by the app. |
|
Thanks for your advice, I will consider using a backout queue. I agree with you on the DLQ, it should not be a dumping ground for bad data. |
|
| Back to top |
|
|
| John89011 |
| Posted: Thu Oct 29, 2009 4:51 am Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
| bruce2359 wrote: |
| Quote: |
| reason is, we received a jms message and our app can not handle jms messages so it hosed the process. |
What do you do in other applications when you have bad (defective) data input?
| Quote: |
| Your best choices are 1) fix the requesting app so it doesn't send defective messages; or 2) fix the replying application so that it processes defective messages. |
Yes, the requesting app already implemented the fix
Our app is still in the works
As pointed out here, a message is a message.
| Quote: |
| Exactly what do you mean by hosed the process? Be specific. Did the app abend? Did it issue any ReasonCode? Anything in the MQ error logs? Was it killed by the o/s? |
|
Here's what happend.. the sending app does a health check every morning (I am assuming they send a request and wait for the response) so someone on their end alterd the script and it started sending jms messages instead of MQ messages.
So, they send a message to our queue, our "request reader" (single threaded)picks up the message and attempts to process it. However, since it was in jms form the app did not know how to handle that message so the request reader was just spinning on that message, preventing all the other messages from going through thus creating a backlog of 5K+ messages.
Under normal conditions, if it's in invalid form or invalid data (depending on the condition) we will discard the request and move on. There were no reason codes and nothing in MQ logs since WMQ did what it suppose to. |
|
| Back to top |
|
|
| John89011 |
| Posted: Thu Oct 29, 2009 4:57 am Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
| fjb_saper wrote: |
Is your app expecting JMS messages or MQ messages?
Have you looked into changing the JNDI of the sending app and set the destinations (queues) up for type MQ and not JMS.
Think uri ?targetClient=1 |
Our app is expecting MQ messages only, nothing new for these apps since it's been working fine for years. Like I mentioned above, changes were made to their health check script and it started sending jms messages instead of MQ. They have since suspended that portion of the health check until they change their script. Oh and did I mention this was Production? |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Thu Oct 29, 2009 6:17 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| John89011 wrote: |
| Oh and did I mention this was Production? |
How can someone change their code directly in PROD without validating in lower level environments?. Dont you guys follow any guidelines/ environmental migration strategies?. |
|
| Back to top |
|
|
| John89011 |
| Posted: Thu Oct 29, 2009 6:21 am Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
| Sam Uppu wrote: |
| John89011 wrote: |
| Oh and did I mention this was Production? |
How can someone change their code directly in PROD without validating in lower level environments?. Dont you guys follow any guidelines/ environmental migration strategies?. |
My point exactly, I don't know how the other app operates but we certainly do implement/test in Dev and UAT before making changes in Prod and a Cahnge Control needs to be sumbitted for the ovious reasons. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Oct 29, 2009 6:31 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Sam Uppu wrote: |
| John89011 wrote: |
| Oh and did I mention this was Production? |
How can someone change their code directly in PROD without validating in lower level environments?. Dont you guys follow any guidelines/ environmental migration strategies?. |
It's funny how often business units sometimes don't follow the processes they mandate...
_________________
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 |
|
|
|
|
