I come from MANY years of transactional financial system. I know how loud the screaming can get when your program drops the ball because you didn't understand the programming concepts. I have been on both ends of the yelling. RTFM!!!! After that ask questions. I have never denied a person a good lenthy lecture on the aspects of MQ. Ask anyone who has met me!!!!
bobbee
From: "Kelly, Steve" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Message Tracking Date: Fri, 30 Apr 2004 11:07:32 -0400
Unfortunately, the biggest thing that continually trips up most developers is their belief in their own ability; there couldn't possibly be anything wrong with their code, could there ?
But seriously, as Bobbee said, its about education; most developers don't understand the implications of what they are coding re. things like persistence, expiry, msgid, correlid, syncpoints etc.
Steve.
-----Original Message----- From: James Kingdon [mailto:[EMAIL PROTECTED] Sent: 30 April 2004 14:31 To: [EMAIL PROTECTED] Subject: Re: Message Tracking
I'd be interested to hear what the most common scenarios are that lead to developers believing that MQ lost their message, particularly when using the JMS API. As has been mentioned in this thread, this isn't the sort of complaint that you hear raised against ftp or databases, but does seem to occur with reasonable frequency with messaging. This might indicate that our APIs aren't as good, or that the underlying paradigm is more complex, but in either case suggests that we could do more to support developers facing the question "where's my message?".
I can think of a few obvious things that crop up on a regular basis:
not starting the JMS Connection sending a message under transaction and not committing incorrectly formed message selectors remote client connections performing receives outside of syncpoint using message expiry publishing messages before creating the subscriber sending the message somewhere other than where it was supposed to go another application left running that consumes from the same destination
With the added power of the MQI there are plenty of additional problems that can arise, like forgetting to clear messageID and correlationID fields when reusing the MQMD, and we haven't yet got to problems of multi-queue manager routing or adding a transformation engine to the mix.
So, let me know what sort of things trip up your developers (or yourselves - I think I've done *all* of the above at sometime or other) and I'll push for features that will hopefully make it easier to support and work with our products.
It would be best if you send problems, not suggestions for solutions - I'm not sure what the IP implications would be for the latter, and I wouldn't want good ideas to be delayed from getting into the product because of legal concerns.
No promises, no time-scales, but rest assured we're listening.
Regards, James.
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
_________________________________________________________________ Check out the coupons and bargains on MSN Offers! http://youroffers.msn.com
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
