java - 使用 BrokeredMessage 消息在 Java 中使用 Azure 队列消息。 getBody() 返回一些头信息，如何摆脱它？

Question

我正在尝试从 Java 接收 Azure 队列消息。我能够使用 java 中的 BrokeredMessage 接收消息。 (我是java新手)。

我的问题是 message.getBody() 也返回一些 header 信息(不仅仅是我需要的消息)。

I get     string3http://schemas.mi@string3http://schemas.microsoft.com/2003/10/Serialization/?? message appended with my body in front of it. How can I get rid of this header information.

而且我还注意到我分两批收到消息。 (不是一次全部)

My first batch of message.getBody()returns below message
'@string3http://schemas.mi'
My Second batch of message.getBody()returns below message
@crosoft.com/2003/10/Serialization/?? + My actual message.

我的消息总大小小于 500B，但我已将字节大小设置为 4096。因此，由于大小问题，这不是夹板。

这是我使用的接收器代码。

ReceiveMessageOptions opts = ReceiveMessageOptions.DEFAULT;
opts.setReceiveMode(ReceiveMode.PEEK_LOCK);

while (true)
{
ReceiveQueueMessageResult resultQM =
service.receiveQueueMessage("MyqueueName", opts);
BrokeredMessage message = resultQM.getValue();
if (message != null && message.getMessageId() != null)
{

byte[] b = new byte[4096];
String s = null;
int numRead = message.getBody().read(b);
while (-1 != numRead)
{
s = new String(b);
s = s.trim();
System.out.print(s);
numRead = message.getBody().read(b);
}
}

}

这是 System.out.print(s); 的总输出。 (但是正如我之前提到的分两批)

total output
string3http://schemas.microsoft.com/2003/10/Serialization/??+ My actual message.

非常感谢任何帮助!

Answer 1

我认为您是从 here 获取上述示例的。在继续阅读代码之前，我们需要了解接收模式锁定类型，即 PeekLock 和 ReceiveAndDelete

接收并删除:

When using the ReceiveAndDelete mode, receive is a single-shot operation - that is, when Service Bus receives a read request for a message in a queue, it marks the message as being consumed and returns it to the application. ReceiveAndDelete mode (which is the default mode) is the simplest model and works best for scenarios in which an application can tolerate not processing a message in the event of a failure. To understand this, consider a scenario in which the consumer issues the receive request and then crashes before processing it. Because Service Bus will have marked the message as being consumed, then when the application restarts and begins consuming messages again, it will have missed the message that was consumed prior to the crash.

窥视:

In PeekLock mode, receive becomes a two-stage operation, which makes it possible to support applications that cannot tolerate missing messages. When Service Bus receives a request, it finds the next message to be consumed, locks it to prevent other consumers receiving it, and then returns it to the application. After the application finishes processing the message (or stores it reliably for future processing), it completes the second stage of the receive process by calling Delete on the received message. When Service Bus sees the Delete call, it will mark the message as being consumed and remove it from the queue.

您正在尝试使用 PeekLock 模式，在该模式下，您需要显式调用 deleteMessage(message) 以便将消息标记为正在使用，除非您没有调用此方法，即使看起来像是被消耗掉了，但实际上并没有被消耗掉。它仍在队列中。

我认为您提到的 header 不是实际的 header ，它是队列中的初始消息，实际上根本没有被消耗

您可以检查这一点，例如更改下面的代码并尝试

if (message != null && message.getMessageId() != null)
{

byte[] b = new byte[4096];
String s = null;
int numRead = message.getBody().read(b);
while (-1 != numRead)
{
s = new String(b);
s = s.trim();
System.out.print(s);
numRead = message.getBody().read(b);
}
//Add the below to ack that you are consumed the message
service.deleteMessage(message);
}    
}