|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
1 MQ Message Per File Vs 1 MQ Message Per Record (MRM Transf |
« View previous topic :: View next topic » |
Author |
Message
|
kirani |
Posted: Wed Nov 21, 2001 1:40 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001 Posts: 3779 Location: Torrance, CA, USA
|
Hi folks,
We would like to transform records in a flat file using MQSI. The input and output formats are created in MRM. An adapter will read the file and put it on a queue.
We have two options to do this transformation,
1. Putting one message per record.
2. Putting one message per file.
I would like to know which method is best with the Pros and Cons of each.
I came up with following points,
One Message per File
Pros
1. More data can be processed at once.
2. Reduces Network traffic.
Cons
1. File needs to be edited such that MQ Message size will not exceed 100MB.
2. Two stage processing may be required to handle different types of records in a file.
3. Counter field needs to be added to the MQ Message, which will hold the record count for MRM parsing.
4. All records will rollback if any error occurs during file processing.
One Message per Record
Pros
1. Easy to parse. We don't need 2 stage processing.
2. File need not be edited.
3. As long as the record size is less than 100 MB we don’t have to do any editing.
4. Transactions can be maintained at record level.
Cons
1. MQ adds its own data with each message while transmitting over network. This could be an overhead if the record length is very small (90 bytes or so).
2. Processing time may increase.
3. Increases Network traffic.
What would be the best solution for handling this type of problem?
Thanks.
Regards,
Kiran
|
|
Back to top |
|
 |
Tibor |
Posted: Wed Nov 21, 2001 4:19 pm Post subject: |
|
|
 Grand Master
Joined: 20 May 2001 Posts: 1033 Location: Hungary
|
Firstly, a comment: I'm using '1 record per message' type transforms and I'm discontent. That's why I'm moving to '1 file per message' message processing.
Quote: |
4. All records will rollback if any error occurs during file processing.
|
From my view this is an advantage... not Con, because I spend a lot of times to re-collect messages when only 1 message go to a fail queue.
|
|
Back to top |
|
 |
kirani |
Posted: Wed Nov 21, 2001 4:36 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001 Posts: 3779 Location: Torrance, CA, USA
|
Hi,
Thanks for your comment on this.
In our case its a con because we have more than one record types (different record structures of same length) in one file. These records are independent of each other so they need not be combined in case of transaction rollback.
In case of 'one message per file', lets say I have 500 records and an error occurs during processing of 450th record, it will rollback all 449 records. Whereas in 'one message per record' I can rollback only one message and continue with others.
It think it really depends on requirements.
Thanks and Happy Thanksgiving!
Regards,
Kiran
|
|
Back to top |
|
 |
Tibor |
Posted: Wed Nov 21, 2001 11:35 pm Post subject: |
|
|
 Grand Master
Joined: 20 May 2001 Posts: 1033 Location: Hungary
|
kiran,
OFF
Thanks for best wishes.
ON
So I said, all solution is case-dependent . '1 record per message' will work good, if you make the message flows watchfully, mostly the splitting and collecting processes.
Important: you have to continue / restart the whole procedure (split - tranform - collect) after a defect.
|
|
Back to top |
|
 |
zpat |
Posted: Tue Nov 27, 2001 3:54 pm Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Large messages will need large MQ logs if processed transactionally. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
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
|
|
|
|