Ruzi, I ran into this at one client also. Here's what I convinced the client to do:
1. Vendor1's application was to supply end-of-day summary data (very large summary, about 5MB of data) to another application. The vendor was told that such large messages were unacceptable, especially since it was expected that the messages would gradually grow larger. Period. End discussion. 2. Vendor2 was told the same thing. This forced both vendors to work together to come up with a better way to exchange the information. Believe it or not, it only took them 2 months. Oh, we did explain our concerns about storage constraints, recoverability, etc., but we all believed it was the no-negotiating stance we took that had the most impact. 3. In the meantime, we used ftp to transfer files between the systems. Like I said, the data was end-of-day summary information that could easily be broken up into application-level segments, with each detail being sent as an individual message, which vendor2 was easily prepared to handle anyway. I suggest you go back to your vendors and discuss the message content and format with them. 60MB is a lot of data, and since it is probably not ONE HUGE record, it could probably be transmitted in pieces. Then again, you did say that QM1 is receiving the data from vendor1 - I an interpreting this to mean a large flatfile - so the segmenting may just become your development headache. You would have to parse the file into components that can be transmitted independently, and then rebuild them on the other side. Of course, it is possible that the receiving vendor may take them as segments - as individual records to process. You'll have to work with the vendors to understand the data and then determine for yourself what the better approach might be. Good luck, let us know how it turns out. Dave Awerbuch IBM Certified MQSeries Specialist APC Consulting Services, Inc. Providing Automated Solutions to Business Challenges West Hempstead, NY (516) 481-6440 [EMAIL PROTECTED] > Date: Wed, 16 Jul 2003 11:08:03 -0700 > From: Ruzi R <[EMAIL PROTECTED]> > Subject: Problem with very very long messages in Production!!! > > Hi all, > > Our platform is WMQ 5.3 CSD3 for NT. We have WMQ > server on two machines with qmgrs QM1 and QM2. The > machine that has the QM1 has 2GB memory and 36GB disk > space (2 * 36 GB mirrored), and the other machine > (having QM2) has 4GB memory and 16GB disk space. > > We are dealing with 2 different vendors on both sides > of the transmission. Developers on QM1 are > receiving messages (from the vendor1 not via MQ > though) well over 60MB and want to send it to vendor2 > on QM2 without making their messages any smaller (by > grouping, segmentation etc. and they say the > compression could not be handled by the receiving > end). Buying a third party product for anything is out > of the question for the company at the moment : ((. > They (the developers) do not know the max msg length > that they would be getting from vendor1. I personally > don t understand how someone cannot know the possible > max msg length they are dealing with. As far as I am > concerned, the limits should always be known in any > interface. These people keep asking us to increase the > msg length almost every other week in production!!!. > They ask me to set the msg length to 20K for instance > and then I find messages for that queue in the DLQ > with the datalength over 60K! Now they are asking me > to temporarily increase one of the queues to 500MB (as > if MQ can handle it!!!) And all these messages are > persistent! I know, writing them to a disk at both > ends, commiting/rollbacking, starting the qmgrs with > this big messages to be restored on their respective > queues would eventually cause a performance hit. They > have already gotten a Java.Lang.OutOfMemoryError for a > 3MB message. I have no idea how these interfaces > passed the different levels of testing up to the > production. I have just started dealing with these > interfaces > > I would like to know if any of you had to deal with > really big messages (over couple of MBs). If so, what > kinds of problems did you have? What is the max msg > length do you allow in Prod? The answer to the last > question depends on the capacity of the machines among > other things, but I just would like to get an idea to > better defend my position on the issue. > > Thanks very much for any input, in advance. > > Ruzi __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.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
