Hi,
I'm a little behind on my emails, so I have not read other peoples responses yet but the 2 biggest problems currently being experienced by my client's JMS / Java programmers are not real problems but more of 'newbie' problems.
Here they are: (1) Having a WebLogic domain with 4 actives nodes and their application deployed and started in all 4 nodes. But they do their development work in a single noded domain and when their application is moved to PTE or a UAT environment, it dies of a horrible death. They either use a 'common' CorrelID value or none at all. Hence, the 4-headed beast is eating its own arms and legs. The messages were not disappearing but rather another node retrieve them!!! Programming 102: Parallelism.
(2) Perceived delays in the messages being delivered. Either they were using syncpointing and they didn't mean too or they were using syncpointing but had a huge UOW (i.e. commit at the end of the program).
Nice to see IBM is listening. :))
Regards, Roger Lacroix Capitalware Inc.
At 09:30 AM 4/30/2004, you wrote:
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
