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
I updated to service bus release 0.9.4 to address 985. However, I now am unable to successfully receive a message with the receive option set to PEEK_LOCK. Here is a code snippet:
ReceiveMessageOptionsopts = ReceiveMessageOptions.DEFAULT;
opts.setReceiveMode(ReceiveMode.PEEK_LOCK);
while (true) {
try {
BrokeredMessagebrokeredMessage = this.fetchBrokeredMessage(opts);
if (brokeredMessage == null) {
break;
}
if (brokeredMessage.getMessageId() == null) {
byte[] body = ByteStreams.toByteArray(brokeredMessage.getBody());
StringcorrelationId = brokeredMessage.getCorrelationId();
LOGGER.error("BODY: " + body.toString());
continue;
}
With a newly created topic and subscription with no outstanding messages, this appears to start dequeuing a long sequence of brokered messages with no message ID, and some small sequence of bytes for the body. Here's sample output:
If a message is queued to the topic, it never is dequeued by this code. I never see the debug logging that shows the message, and it appears on the subscription as seen from the portal.
If I roll back the service bus dependency to 0.9.3, I am again able to successfully use PEEK_LOCK, but this causes other problems since jersey 1.13 has compatibility difficulties with Dropwizard.
This seems behavior consistent with another, older report in 644 that reports needing to roll back the jersey dependency in order to get PEEK_LOCK to work.
The text was updated successfully, but these errors were encountered:
I updated to service bus release 0.9.4 to address 985. However, I now am unable to successfully receive a message with the receive option set to PEEK_LOCK. Here is a code snippet:
With a newly created topic and subscription with no outstanding messages, this appears to start dequeuing a long sequence of brokered messages with no message ID, and some small sequence of bytes for the body. Here's sample output:
If a message is queued to the topic, it never is dequeued by this code. I never see the debug logging that shows the message, and it appears on the subscription as seen from the portal.
If I roll back the service bus dependency to 0.9.3, I am again able to successfully use PEEK_LOCK, but this causes other problems since jersey 1.13 has compatibility difficulties with Dropwizard.
This seems behavior consistent with another, older report in 644 that reports needing to roll back the jersey dependency in order to get PEEK_LOCK to work.
The text was updated successfully, but these errors were encountered: