ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Java / JMS » Traversing messages in Queue.

Post new topic  Reply to topic Goto page Previous  1, 2
 Traversing messages in Queue. « View previous topic :: View next topic » 
Author Message
bower5932
PostPosted: Wed Sep 10, 2008 7:38 am    Post subject: Reply with quote

Jedi Knight

Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA

Rohit_ wrote:
How this situation is handled in MQ?


You need to look into units of work. You would get all of your messages under syncpoint, perform your other work, and then either commit or rollback the messages.

You wouldn't leave messages laying around and try to keep track of what you have or have not processed.
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger
Rohit_
PostPosted: Wed Sep 10, 2008 11:14 am    Post subject: Callback with MQ v6. Reply with quote

Novice

Joined: 10 Jan 2008
Posts: 24

It seems like the only way to implement callback in IBM MQ v6 is thru triggers.

But triggers comes with lots of trade-offs. my MQ v6 server is installed on UNIX platform.any other way where i can implement callback?
or MQ v7 is the only option left?
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Sep 10, 2008 2:22 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Looks more and more like a pub/sub problem to me.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Rohit_
PostPosted: Wed Sep 10, 2008 4:02 pm    Post subject: Reply with quote

Novice

Joined: 10 Jan 2008
Posts: 24

Yes you can say that.from Biz perspective it's like pub/sub.

So I can implement this with MQSeries Publish/Subscribe broker ?
I don't have to use JMS. while I am reading manual can some please explain
the difference between implementing this way or by using callback function?

am confused,no idea if am making any sense with this question?
Back to top
View user's profile Send private message
Rohit_
PostPosted: Wed Sep 10, 2008 5:17 pm    Post subject: Reply with quote

Novice

Joined: 10 Jan 2008
Posts: 24

No this is not pub/sub problem. messages are not published nor my application needs to subscribe to some Topic.

I don't want to use triggers for other trade offs. and I just need callback function to implement this.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Sep 10, 2008 8:02 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Rohit_ wrote:
No this is not pub/sub problem. messages are not published nor my application needs to subscribe to some Topic.

I don't want to use triggers for other trade offs. and I just need callback function to implement this.


Define call back function. The nearest that I can think of is the MessageListener in JMS/XMS. In non JMS terms this comes either to a long running program, or a triggered program.

The reason I was leaning towards pub/sub is that you would have multiple receivers get the message and the receivers would be entirely decoupled from each other.

Going back to my rant some posts above: If you browse the message because you need to do something about or with the msg content, there is something wrong in your app design. You should either consume the message or leave it alone.

If you browse the messages to know how many are in the queue, this is a monitoring task and browsing is ill suited for that. Use some monitoring messages (pcf see MS0B) to ask for the queue depth. It's faster and has by far less overhead than browse....

If you browse your messages to see the content and understand what is going on in your app, => that is a development task with human intervention (use rfhutil or some other development tool) and should not be coded for.

And finally if you browse your messages because you only want to consume them when you are sure that some other tasks dependent on message content are completed with success => this is a transactional matter and you are so using the wrong pattern. You should be using single or multiple phase commit.

Enjoy
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Rohit_
PostPosted: Thu Sep 11, 2008 6:33 am    Post subject: Reply with quote

Novice

Joined: 10 Jan 2008
Posts: 24

fjb_saper,

Yes you are absolutely right. My application has to just consume messages.
Now I am bound to use MQ v6 and in Non JMS context I have two options to consume messages async.
a)Triggers
b)A continous running thread,which notify my application on arrival on new message.

incase,if you are aware of some sample code please let me know.
(program to continous poll queue,and notify parent application)

many thanks.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Thu Sep 11, 2008 6:41 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

If you have to ask where to find sample code, you are not paying *any* attention at all.

Please try harder.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » IBM MQ Java / JMS » Traversing messages in Queue.
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.