| Author |
Message
|
| banjar1 |
 Posted: Mon Oct 15, 2007 9:25 am Post subject: |
 |
|
Acolyte
Joined: 29 Nov 2006
Posts: 54
Location: FRA
|
| That's not exactly what happened here. I don't have a DLQ so not even one message goes there. Probably broker tries to put the first message there forever... |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Oct 15, 2007 2:15 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
| banjar1 wrote: |
| That's not exactly what happened here. I don't have a DLQ so not even one message goes there. Probably broker tries to put the first message there forever... |
The point is you need a DLQ.
If your messages are persistent and time sensitive you need the receiver system to be able to handle messages out of order....
Now it should be very easy to run a DLQ handler to resubmit messages for queue Xyz...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| banjar1 |
| Posted: Mon Oct 15, 2007 10:27 pm Post subject: |
|
|
Acolyte
Joined: 29 Nov 2006
Posts: 54
Location: FRA
|
Ok, once more: my question is NOT about if we need DLQ or not. We know we don't. Trust me.
I want to know if there is a way to "reset/resolve" a stream so it would stop trying to put anything on DLQ, but would retry to deliver a message to subscriber rather.
This is what I expected:
| Quote: |
| If the broker cannot put a publication message onto a destination queue or the dead-letter queue, and cannot discard the message, the broker continues trying to put the publication message onto the destination queue (at suitable intervals) and does not continue processing subsequent messages. |
I wonder why my broker does not act like that, but instead keeps complaining about missing DLQ. Can it be because it is a built-in only?
A question on a side for all DLQ fans: in a situation, where you have a constant stream of messages (thousands per hour), how do you make sure that messages from DLQ are processed before any new regular message? In other words: how do you make sure, that messages from DLQ and regular feed are delivered in proper order?
|
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 15, 2007 11:16 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| banjar1 wrote: |
A question on a side for all DLQ fans: in a situation, where you have a constant stream of messages (thousands per hour), how do you make sure that messages from DLQ are processes before any new regular message? In other words: how do you make sure, that messages from DLQ and regular feed are delivered in proper order?
|
By ensuring at a design stage that message order is irrelevant. Messages that rely on the message preceeding them are said to have message affinity. This is especially important when you're processing thousands or tens of thousands of messages per hour, as it allows you to spin up new instances of queue managers & servicing applications to take the load without a moment's thought about which instance of the application is handling which part of the message stream.
It also means that the channel doesn't unexpectedly stop causing a massive backlog in the xmitq, just a huge pile of undelivered messages in the DLQ while the rest go through. Doesn't avoid the need to monitor the channel like everything else, but does limit the size of the explosion when something happens. And allows for some automated management via the DLQ handler.
My personal take on this (other views are equally if not more valid) is that the messages do not have a sequence, but the data does. Typically this maps to a business process. If an unexpected message is received this must be held at target until the previous process is completed, or raised as an exception if the previous process doesn't complete within SLA. A side effect of this which I've noticed is that once people start thinking in these terms, the chain of a process tends to break down into parallel processes given process improvements.
Again, a personal view, nothing stronger than that.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| banjar1 |
| Posted: Mon Oct 15, 2007 11:29 pm Post subject: |
|
|
Acolyte
Joined: 29 Nov 2006
Posts: 54
Location: FRA
|
I suspected something like that. I shall explain what type of messgaes we deal with. Have you heard of NOTAMs? NOtes To AirMen? They are issued by virtually everybody in the aviation industry (from airports to airlines to FAA/IATA) and must be delivered to all our customers (airlines). They can also be cancelled at any time - and we have to make sure that such a cancellation does not arrive before the actual NOTAM. Do you get my point now? We can't use DLQ.
Now, I have just re-run the test and the result is the same: once the subscriber queue got full the broker started trying to put a message on DLQ - and does not retry to put it on subscriber queue even it is available now.
| Quote: |
AMQ5856: Broker publish command message cannot be processed. Reason code 2195.
EXPLANATION:
The WebSphere MQ Publish/Subscribe broker failed to process a publish message
for stream (TEST.STREAM ). The broker was
unable to write the publication to the dead-letter queue and was not permitted
to discard the publication. The broker will temporarily stop the stream and
will restart the stream and consequently retry the publication after a short
interval.
ACTION:
Investigate why the error has occurred and why the publication cannot be
written to the dead-letter queue. Either manually remove the publication from
the stream queue, or correct the problem that is preventing the broker from
writing the publication to the dead-letter queue. |
Is it normal for built-in brokers? Can I recover from that without creating DLQ nor losing a message? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 15, 2007 11:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| banjar1 wrote: |
| Have you heard of NOTAMs? NOtes To AirMen? They are issued by virtually everybody in the aviation industry |
Yes I have, I've worked on a related system and a DLQ works fine. Though I agree that wasn't a situation where the process went especially parallel! 
But as you say, you're not here to discuss the merits of a DLQ as your mind is made up. You're here to try and bash the system into the shape you want it to take.
I stand by my previous post on the subject (further up this chain) and wait for wiser (possibly IBM) minds to correct me or suggest other solutions.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| banjar1 |
| Posted: Tue Oct 16, 2007 12:14 am Post subject: |
|
|
Acolyte
Joined: 29 Nov 2006
Posts: 54
Location: FRA
|
| Quote: |
| You're here to try and bash the system into the shape you want it to take. |
I can't really agree with that. I'm rather looking for an answer why the system does not behave as documented and expected (also see my posts above). |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 16, 2007 12:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| banjar1 wrote: |
| Quote: |
| You're here to try and bash the system into the shape you want it to take. |
I can't really agree with that. I'm rather looking for an answer why the system does not behave as documented and expected (also see my posts above). |
An unfortunate choice of phrase perhaps.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 16, 2007 1:52 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
banjar1 - it's an interesting problem.
Also, your error message that you've posted exactly lines up with the behavior in the documentation that vmcgloin posted.
But if I understand your setup, the only time you'll ever run into this problem in real life is if the local Transmission queue on your side fills up. So you can take steps to make sure that this doesn't happen.
The other thing to look at is the pub/sub in Message Broker/Event Broker. I don't believe it has this same issue, and it will perform better. On the other hand, it's more expensive.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| banjar1 |
| Posted: Tue Oct 16, 2007 2:05 am Post subject: |
|
|
Acolyte
Joined: 29 Nov 2006
Posts: 54
Location: FRA
|
| jefflowrey wrote: |
| your error message that you've posted exactly lines up with the behavior in the documentation that vmcgloin posted. |
How so? If I read the docu correctly, the broker should keep retrying to put the message on subscriber queue (message is persistent, no DLQ available). It only tries to put it to DLQ instead and ignores already available subcriber queue.
I'm also not so sure that this is the only situation I have such a problem. It is perfectly possible to have a configuration problem when adding new customer (misspelling in some definition for example) and what then? Again DLQ is required? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 16, 2007 2:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Your point about bad configuration is what test environments and scripted production deployments are for, but...
Does it help to restart the broker?
Also, you are on v6 with a recentish FP, right?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| banjar1 |
| Posted: Tue Oct 16, 2007 2:20 am Post subject: |
|
|
Acolyte
Joined: 29 Nov 2006
Posts: 54
Location: FRA
|
| jefflowrey wrote: |
| Does it help to restart the broker? |
Nop. I tried that. It tries to write to DLQ also immediately after restart.
| jefflowrey wrote: |
| Also, you are on v6 with a recentish FP, right? |
That's what we have:
mqm.base.runtime 6.0.2.1 COMMITTED WebSphere MQ Runtime for
mqm.base.samples 6.0.2.1 COMMITTED WebSphere MQ Samples
mqm.base.sdk 6.0.2.1 COMMITTED WebSphere MQ Base Kit for
mqm.client.rte 6.0.2.1 COMMITTED WebSphere MQ Client for AIX
mqm.java.rte 6.0.2.1 COMMITTED WebSphere MQ Java Client, JMS
mqm.keyman.rte 6.0.2.1 COMMITTED WebSphere MQ Support for GSKit
mqm.msg.en_US 6.0.2.1 COMMITTED WebSphere MQ Messages - U.S.
mqm.server.rte 6.0.2.1 COMMITTED WebSphere MQ Server
mqm.txclient.rte 6.0.2.1 COMMITTED WebSphere MQ Extended
mqm.base.runtime 6.0.2.1 COMMITTED WebSphere MQ Runtime for
mqm.man.en_US.data 6.0.2.1 COMMITTED WebSphere MQ Man Pages - U.S. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 16, 2007 2:25 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Well... it's probably time to open a PMR.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Oct 16, 2007 6:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| jefflowrey wrote: |
| Well... it's probably time to open a PMR. |
I agree.
While I'm far from a Pub Sub expert, we recently started using it here and I've read the Pub Sub Manual cover to cover. I checked it again and still fail to explain your behaviour. It does not seem to work as it should in your case.
Do you get the same results if the subscription queue is put inhibited? Do messages go to the queue once you enable it?
Please post the solution once you find it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| banjar1 |
| Posted: Tue Oct 16, 2007 10:53 pm Post subject: |
|
|
Acolyte
Joined: 29 Nov 2006
Posts: 54
Location: FRA
|
| PeterPotkay wrote: |
Do you get the same results if the subscription queue is put inhibited? |
Yes.
| PeterPotkay wrote: |
| Do messages go to the queue once you enable it? |
No.
I will post the solution - if there is one... |
|
| Back to top |
|
|
|
|
