| Author |
Message
|
| leoChina |
 Posted: Thu Mar 05, 2009 10:07 pm Post subject: MQ cursor |
 |
|
Novice
Joined: 04 Sep 2008
Posts: 14
|
Dear all,
Does MB getting messages from MQ have cursor just like oracle.and we can choose when to read the next message instead of reading it as soon as queue contains a message.and we can read the second message instead of the first.
thanks all.
leo |
|
| Back to top |
|
 |
| MQEnthu |
| Posted: Thu Mar 05, 2009 10:32 pm Post subject: |
|
|
Partisan
Joined: 06 Oct 2008
Posts: 329
Location: India
|
| leoChina wrote: |
| we can choose when to read the next message instead of reading it as soon as queue contains a message.and we can read the second message instead of the first. |
Message flow picks up the message as soon as the message arrives in the queue (as long as flow is running and Queue is get NOT get inhibited).
In V6.1,You can browse the messages in the queue and get the desired messages using MQInput and MQGet nodes. You can refer to the "Browsing WebSphere MQ Queues sample" in sample gallery to get a better understanding...
_________________
-----------------------------------------------
It is good to remember the past,
but don't let past capture your future |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 06, 2009 1:24 am Post subject: Re: MQ cursor |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| leoChina wrote: |
| Does MB getting messages from MQ have cursor just like oracle |
No. Why would you want one?
| leoChina wrote: |
| we can choose when to read the next message instead of reading it as soon as queue contains a message |
Yes. Use a Timer node or schedule the flow with external software.
| leoChina wrote: |
we can read the second message instead of the first.
|
No. Why would you want to?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| leoChina |
| Posted: Sat Mar 07, 2009 7:22 am Post subject: Re: MQ cursor |
|
|
Novice
Joined: 04 Sep 2008
Posts: 14
|
| Vitor wrote: |
| No. Why would you want to? |
i want to control the number of message processed by message-flow per minute.
And sometimes the first message in the queue should not be processed first. i must process the other messages and then the first one.
thanks for your reply! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Mar 07, 2009 9:16 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There are mechanisms in MQ to read messages in "logical" order, and they are documented in the manuals. But the messages must be *constructed* in such a way that there is a clearly identified logical order.
There are no mechanisms in MQ to "pause" a queue such that an outstanding GET will not receive the next message in the exact instant that that message is available.
You have very bad business requirements, or very bad technical solutions to misunderstood business requirements.
You should rethink your solution to avoid message affinity (where you must process Message A before you process Message B) at all costs, and you should rethink your solution to avoid having to manage workflow by controlling the number of messages processed per minute. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Mar 07, 2009 9:41 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
There is a fundament concept with Message Queueing systems that I guess you don't appreciate.
This is the concept of a Queue.
Queues are typically
LIFO
FIFO
Priority Ordered.
WMQ is by default FIFO with Priority Override.
The sender can decide the priority of the message they send. This allows an important message to 'jump' the queue so to speak. This is not really commonly used though.
Broker as a WMQ Message consumer can't decide which message (the first, second or nth) to read without some other information. You can get a message by Message ID or CorrelID but that is just about it.
Unless messages are grouped then a message consumer will typically read the first message in the Queue and process it.
Then it will read the next one and process it.
In your scenario how do you expect broker to know which (first, second or nth) message to read?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| leoChina |
| Posted: Sun Mar 08, 2009 8:12 pm Post subject: |
|
|
Novice
Joined: 04 Sep 2008
Posts: 14
|
| smdavies99 wrote: |
| In your scenario how do you expect broker to know which (first, second or nth) message to read? |
Thanks for your reply.The XML in the queue can tell the broker to read which message.e.g,there are three message in the queue.
1,<message>
<id>1</id>
<text>aaa</text>
</message>
2,<message>
<id>1</id>
<text>bbb</text>
</message>
3,<message>
<id>2</id>
<text>ccc</text>
</message>
if the first message failed,the third message should be read instead of the second.until the first has success after retrying,the second one should read by the broker. ID makes the messages associated.The second could not be read if the first with the same id failed.
can MQ or MB do this?Or we should write JAVA for it?
thanks all. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Mar 08, 2009 11:35 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| leoChina wrote: |
| can MQ or MB do this?Or we should write JAVA for it? |
You shouldn't do it at all. This is message affinity and there has been many, many discussions of why this is a bad idea.
If messages with the same id need to be processed as a block or not at all you should use the grouping mechanism to ensure they're ignored until all are present. If a message fails, it should be moved to a backout queue rather than left on the input queue and read over.
Take a cold, hard look at your design. Then fix it. Then you'll be able to use the facilities built into the products rather than trying to code round them. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Mar 09, 2009 2:13 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| chids |
| Posted: Mon Mar 09, 2009 5:14 am Post subject: |
|
|
Novice
Joined: 09 Oct 2006
Posts: 22
Location: Stockholm, Sweden
|
| Vitor wrote: |
If messages with the same id need to be processed as a block or not at all you should use the grouping mechanism to ensure they're ignored until all are present. If a message fails, it should be moved to a backout queue rather than left on the input queue and read over.
Take a cold, hard look at your design. Then fix it. Then you'll be able to use the facilities built into the products rather than trying to code round them. |
_________________
/mårten.
-- http://marten.gustafson.pp.se/
-- marten.gustafson@gmail.com |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Mar 09, 2009 5:16 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqjeff wrote: |
You have very bad business requirements, or very bad technical solutions to misunderstood business requirements.
You should rethink your solution to avoid message affinity (where you must process Message A before you process Message B) at all costs, and you should rethink your solution to avoid having to manage workflow by controlling the number of messages processed per minute. |
|
|
| Back to top |
|
|
|
|
