java JMS 消息大小
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/7090028/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
JMS message size
提问by Sorceror
I'm currently working on bandwidth limiting feature (don't ask me why, its not my decision) for application which use JMS (Spring framework JMS and Active MQ namely) to sending messages with payload between server and clients.
我目前正在为使用 JMS（即 Spring 框架 JMS 和 Active MQ）在服务器和客户端之间发送带有有效负载的消息的应用程序开发带宽限制功能（不要问我为什么，这不是我的决定）。
I found lot of throttling methods to limit incoming JMS messages (but none of them based on actual bandwidth load), however I didn't find any possible way to limit outgoing message flow. So I decided to write Leaky bucket algorithmon my own.
我发现了很多限制传入 JMS 消息的方法（但没有一个基于实际带宽负载），但是我没有找到任何可能的方法来限制传出消息流。所以我决定自己编写漏桶算法。
Is there some way how to obtain size of JMS message?Other than 'sizeof' implementation in Java (In Java, what is the best way to determine the size of an object?)
有什么方法可以获取 JMS 消息的大小吗？除了 Java 中的“sizeof”实现（在 Java 中，确定对象大小的最佳方法是什么？）
采纳答案by Sorceror
Because JMS messages are serialized in sending process, the best way how to obtain size of message is through ObjectOutputStream.
由于 JMS 消息在发送过程中被序列化，因此获取消息大小的最佳方式是通过 ObjectOutputStream。
private int getMessageSizeInBytes(MessageWrapper message) throws IOException {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(message);
oos.close();
return baos.size();
}
回答by AlexR
I do not think that you have any seriously better alternative to determine the JMS message size than measuring of its serialized size.
我认为您没有比测量其序列化大小更好的替代方法来确定 JMS 消息大小。
But you can add some optimizations if you want. There are several types of messages (e.g. MapMessage, ObjectMessage, TextMessage).
但是您可以根据需要添加一些优化。有几种类型的消息（例如 MapMessage、ObjectMessage、TextMessage）。
The size of text message is the length of its text. The size of map message is the total size of all its fields. The fields are primitives or java.util.Date, so it is not a problem to measure them. Object message contains serializable object, so you can measure its size by writing to ByteOutputStream.
文本消息的大小是其文本的长度。地图消息的大小是其所有字段的总大小。字段是原始类型或 java.util.Date，因此测量它们不是问题。对象消息包含可序列化的对象，因此您可以通过写入 ByteOutputStream 来测量其大小。
I think that implementation of leaky bucket using JMS may be simplified if you are using hidden feature of most JMS providers to send delayed messages. You can measure the message when enqueueing it and decide when do you want the subscriber to receive it. Please read here for details of how to send delayed messages: http://alexradzin.blogspot.com/2010/10/send-delayed-jms-messages.html
我认为，如果您使用大多数 JMS 提供程序的隐藏功能来发送延迟消息，那么使用 JMS 实现漏桶可能会得到简化。您可以在排队时测量消息并决定您希望订阅者何时接收它。有关如何发送延迟消息的详细信息，请阅读此处：http: //alexradzin.blogspot.com/2010/10/send-delayed-jms-messages.html
回答by strmqm
In addition to the earlier comment by @AlexR, BytesMessage has a getBodyLength() method
除了@AlexR 之前的评论之外，BytesMessage 还有一个 getBodyLength() 方法
http://download.oracle.com/javaee/1.4/api/javax/jms/BytesMessage.html#getBodyLength
http://download.oracle.com/javaee/1.4/api/javax/jms/BytesMessage.html#getBodyLength
and you can probably estimate typical header size in transit by capturing a few objects created using Session.createMessage() - i.e. the JMS message type with no payload. I think i'd be tempted to work directly with a payload in a byte[], using a BytesMessage, and compress via a ZipOutputStream if bandwidth is critical. In addition, JMS allows hints to suppress message timestamp and message id, which may help reduce message size e.g.
并且您可以通过捕获使用 Session.createMessage() 创建的一些对象来估计传输中的典型标头大小 - 即没有有效负载的 JMS 消息类型。我想我很想直接使用 byte[] 中的有效负载，使用 BytesMessage，如果带宽很关键，则通过 ZipOutputStream 进行压缩。此外，JMS 允许提示抑制消息时间戳和消息 ID，这可能有助于减少消息大小，例如
although providers are not required to support it,
虽然不需要提供者支持，
If the JMS provider accepts this hint, these messages must have the message ID set to null; if the provider ignores the hint, the message ID must be set to its normal unique value
如果 JMS 提供者接受此提示，则这些消息的消息 ID 必须设置为 null；如果提供者忽略提示，则消息 ID 必须设置为其正常的唯一值
I once worked with very bandwidth-limited JMS on WebSphere MQ everyplace, and it was possible to get the message size pretty small in this way - although the native wireframe format was also optimised for size in that case
我曾经在 WebSphere MQ 上的任何地方使用带宽非常有限的 JMS，并且可以通过这种方式使消息大小非常小 - 尽管在这种情况下原生线框格式也针对大小进行了优化
