我正在尝试从Websphere MQ队列中读取100 MB的文件。文件应包含约。 800.000条记录。但是在某个行号(通常在90.000左右)之后,我只得到空(或者可能是#65533,具体取决于我如何查看文件)。
我被告知队列应该允许100 MB消息。
我的代码:
canActivate
这段代码出了什么问题?或者是发送方的错误?
答案 0 :(得分:0)
目前尚不清楚被问及的是什么,我相信这是问题的根源。虽然MQ可以处理大小高达100MB的消息,但问题并非如此。
我正在尝试从Websphere MQ队列中读取100 MB的文件。文件 应该包含约。 800.000条记录。但经过一定的行数 (通常在90.000左右)
隐藏在该单一陈述中的是对:
的引用我确信你问的每个人都在回应队列,因此一再保证MQ可以处理100MB的消息。但代码似乎是重新组合文件,该文件被分成一个记录/行 / 消息。这是一个完全不同的用例。
一次采用这一个,在MQ中完全可以来回传递100MB的消息。这样做需要从MAXMSGL
的4MB默认值配置该路径上的每个QMgr,通道和队列。不太明显的是,如果使用线性日志和/或在同步点下处理消息,则必须有足够的日志空间来包含多个100MB事务。默认日志范围计数和大小不会预期100MB消息。最后,应用程序需要提供足够大的缓冲区,并确保不要告诉MQ允许截断的消息。
这种通过MQ移动文件的方法仅限于100MB以下的文件,但具有原子操作的独特优势 - 要么是GET / PUT整个文件,要么根本没有。没有缺少的部分,没有任何乱序等。这大大简化了代码。
第二种可能性是代码重新组合了一个被分成许多消息的文件。发布的代码片段实际上想要向对方追加多条100MB消息似乎令人怀疑,所以我假设它正在尝试从许多消息中重新组合文件。 (我相信最多800,000。)在这种情况下,问题是在一个工作单元中可以有多少消息。代码片段省略了任何有意义的错误处理,因此我假设同步点处理也被省略了。
重新组装文件时出现的错误包括无序消息和丢失消息。即使是每个文件使用多个消息的最简单的基于MQ的文件移动器也需要使用同步点来确保整个文件作为一个单元发送或接收。但MQ不会在单个工作单元中预测800,000条消息,因此您需要同时调整日志范围 和 MAXUMSGS
以执行任何操作。琐碎的案子。
当然,移动文件并在分割成许多消息时保证其完整性并非易事,当所有排列都被考虑时,结果看起来很像MQ Managed File Transfer。
回到这个问题,如果文件是在单个消息中传输的,并且没有设置截断消息的API选项,那么MQ API中没有任何内容会影响消息之后的消息一些行数或消息长度。在这种情况下,解释垃圾超过某一点的唯一方法是发送应用程序发送它。 (例如,分配100MB缓冲区,填充50MB,然后发送100MB消息。)
但是,如果文件被分割成代码中显示的许多消息,则必须执行上述调整。其中包括将MAXUMSGS
提升到大于800,000(doc link)的值,并确保主要和辅助日志范围中有足够的空间来容纳几个大的工作单元。有关详细信息,请参阅Calculating the size of the log。
另外,您可能还希望每次都重置MQGMO
,因为正如该对象的Overview所述,它既是输入又是输出。
修改后的代码看起来更像是这样:
MQGetMessageOptions gmo = new MQGetMessageOptions();
for (int i = 0; i < maxMessagesToRead; i++)
{
var mqMessage = new MQMessage();
gmo.Options = MQC.MQGMO_NO_WAIT;
mqQueue.Get(mqMessage, gmo);