Closed BruAlcaraz closed 5 months ago
Strange.
It may be the way the messages are displayed. I think the tool guesses how the message should be displayed. Please check a message that looks good in Service Bus Explorer in another tool, such as the Azure Portal Service Bus Explorer, if those characters exist in that message.
If those characters are not there in question 1 I wonder if you are sure they are added by Service Bus Explorer?
Does this happen if you resubmit messages one by one?
@BruAlcaraz, the sender of the message is using a really old SDK and likely sending the payload which gets serialized with old ASB's internal serializer rather than a stream of bytes. What's the SDK used to generate the message and the specific code that sends it?
Hi @ErikMogensen 1) in the Original message the characters are not there. 2) they only get there after I resend via batch but strangely enough the issue does not happen always. 3) no it never happens when resending one by one. But once the issue happens in that batch that I need to resend one by one and make sure to delete the added characters.
@BruAlcaraz, the sender of the message is using a really old SDK and likely sending the payload which gets serialized with old ASB's internal serializer rather than a stream of bytes. What's the SDK used to generate the message and the specific code that sends it?
I'll double check it in the morning and get back to you. But as I mentioned to Erik the characters only shows when the messages are resent in a batch never happened on any originally sent messages.
the characters only shows when the messages are resent in a batch never happened on any originally sent messages.
That's good, let's narrow the scope to that code then, to see how the message batch is resubmitted. Thanks.
Has there been any updates or finds on this thread. It's an issue I'm seeing also when re-submitting in batch.
I'm noticing this issue as well.
Those random characters look exactly like the message encoding when the (very old, deprecated) WindowsAzure.ServiceBus is used to send the message. Should really look at getting onto Azure.Messaging.ServiceBus . (If it is already updated and still doing that ... huh)
I think the problem is in https://github.com/paolosalvatori/ServiceBusExplorer/blob/main/src/ServiceBusExplorer/Forms/MessageForm.cs#L418 The body is read as a Stream and that won't work if body type is String.
message.Clone(message.GetBody<Stream>(), messagesSplitContainer.Visible);
Maybe it is enough to check if bodyType == BodyType.String
and if true do message.GetBody<string>()
instead. Just make sure it does not break anything else.
I am having this problem happen fairly regularly lately, even after upgrading to latest. Has there been any movement on a potential fix for this issue?
I'm seeing this as well. I wonder if it is related to the scenario where we try to submit too many records to be resubmitted and we hit the lock timeout?
I have noticed that as @tscbp Mentioned it only happens with messages queued by our legacy system which is probably using a deprecated package to queue messages. I have tried to find a solution in the Bus explorer myself but with no success as it is a hard scenario to replicate and I was never able to find steps to replicate it consistently
I addressed this issue based on @FredrikDahlberg's suggestion and opened a pull request. Hope this helps! https://github.com/paolosalvatori/ServiceBusExplorer/pull/764
Hi, I am facing an issue sometimes when I use the Batch Mode to resubmit multiple messages. Sometimes the messages resubmitted have a string added to it '@strin3http://schemas.microsoft.com/2003/10/Serialization/�' It has happened sometimes not every time. Can anyone help me with that?
Current Version that I am using is 5.0.7 but it happened on other versions as well