You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
None of the MQP message protocols define a maximum message size, but message queuing brokers are optimized for small messages. Brokers of all MQP achieve their highest performance forwarding many small messages, rather than few large ones. Even rare Large messages can have an outsized effect on performance by requiring buffers on brokers to expand for those rare cases, so keeping messages are uniformly "small" is necessary for best performance.
The renewal of MQP protocol usage in GTS aims to have only announcements of products, not to transport the data itself, which is a particularly easy way to get smaller messages. However, many people with long experience with other messaging protocols expect the old methods, where products themselves were included in the files ( examples #36 ) and the Aviation people seem to want data to be included in the body as well. This is unlikely to scale well.
The aviation people have mentioned 8MB as a maximum product size for aviation. We believe that, whatever method is adopted by other groups, they will eventually find themselves wanting to send products larger than the maximum, and will eventually be faced with two choices: either they add support for links to data, as we have already done, or they introduce segmentation. Having that choice happen at a large message size is likely worse for performance.
The old GTS 386 limit was 500,000 bytes, which already sounds relatively large. That's already a high number in my view, but I think the committee was interested in doing some performance studies before settling on a recommendation. So this is a placeholder for now.
The text was updated successfully, but these errors were encountered:
None of the MQP message protocols define a maximum message size, but message queuing brokers are optimized for small messages. Brokers of all MQP achieve their highest performance forwarding many small messages, rather than few large ones. Even rare Large messages can have an outsized effect on performance by requiring buffers on brokers to expand for those rare cases, so keeping messages are uniformly "small" is necessary for best performance.
The renewal of MQP protocol usage in GTS aims to have only announcements of products, not to transport the data itself, which is a particularly easy way to get smaller messages. However, many people with long experience with other messaging protocols expect the old methods, where products themselves were included in the files ( examples #36 ) and the Aviation people seem to want data to be included in the body as well. This is unlikely to scale well.
The aviation people have mentioned 8MB as a maximum product size for aviation. We believe that, whatever method is adopted by other groups, they will eventually find themselves wanting to send products larger than the maximum, and will eventually be faced with two choices: either they add support for links to data, as we have already done, or they introduce segmentation. Having that choice happen at a large message size is likely worse for performance.
The old GTS 386 limit was 500,000 bytes, which already sounds relatively large. That's already a high number in my view, but I think the committee was interested in doing some performance studies before settling on a recommendation. So this is a placeholder for now.
The text was updated successfully, but these errors were encountered: