Ребус помещает странные символы в словарь HEADER JSON, написанный в MSMQ Extension Property - PullRequest
0 голосов
/ 11 мая 2018

У меня есть приложение, которое пишет сообщение, используя шаблон публикации / подписчика с реализацией Rebus. В какой-то момент, без каких-либо изменений кода, Ребус начал писать двоичное содержимое Расширения MSMQ с некоторыми странными символами после содержимого JSON, вот пример одного принятого сообщения с проблемой:

{ "rbs2-намерения": "паб", "rbs2-сообщ-идентификатор": "ac543d60-e28c-49bb-8783-b5c6574a90ea", "rbs2-возвратного адрес": "myqueuename @ SERVERNAME", "rbs2 -senttime ":" 2018-04-26T00: 20: 48.0453055-03: 00" , "rbs2-корр-идентификатор": "ac543d60-e28c-49bb-8783-b5c6574a90ea", "rbs2-корр-сл": "0 " "rbs2-сообщ типа":" ClassNamespace.BusinessClassName, ClassNamespace», "rbs2-тип содержимого": "приложения / JSON; кодировка = UTF-8", "rbs2-Content-Encoding": "GZIP"} K H 3 ??? ? / ?? ш

Вот полное сообщение об ошибке, которое я получаю в лог-файле lof4net, написанное Rebus при получении сообщения от MSMQ.

2018-05-03 10: 33: 49,516 ВНИМАНИЕ Rebus.Workers.ThreadPoolBased.ThreadPoolWorker - Произошла ошибка при попытке получить следующее сообщение: System.Runtime.Serialization.SerializationException: не удалось десериализовать текст JSON { "Rbs2-намерение": "паб", "rbs2-сообщ-идентификатор": "ac543d60-e28c-49bb-8783-b5c6574a90ea", "rbs2-возвратный адрес": "myqueuename @ SERVERNAME", "rbs2-senttime ":" 2018-04-26T00: 20: 48.0453055-03: 00" , "rbs2-корр-идентификатор": "ac543d60-e28c-49bb-8783-b5c6574a90ea", "rbs2-корр-сл": "0", "rbs2-сообщ типа": "ClassNamespace.BusinessClassName, ClassNamespace», "rbs2-тип содержимого": "приложения / JSON; кодировка = UTF-8", "rbs2-Content-Encoding": "GZIP"} K H 3 ??? ? / ?? W R? ? Newtonsoft.Json.JsonReaderException: Дополнительный текст обнаружен после завершения чтения содержимого JSON:. Путь '', строка 1, позиция 432. в Newtonsoft.Json.JsonTextReader.Read () в Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize (JsonReader читатель, тип objectType, логическое checkAdditionalContent) в Newtonsoft.Json.JsonSerializer.DeserializeInternal (читатель JsonReader, Тип objectType) в Newtonsoft.Json.JsonConvert.DeserializeObject (строковое значение, тип Type, Настройки JsonSerializerSettings) в Newtonsoft.Json.JsonConvert.DeserializeObject [T] (строковое значение, Настройки JsonSerializerSettings) в Rebus.Serialization.HeaderSerializer.DeserializeFromString (String str) --- Конец внутренней трассировки стека исключений --- в Rebus.Serialization.HeaderSerializer.DeserializeFromString (String str) в Rebus.Msmq.MsmqTransport.d__15.MoveNext () --- Конец стека трассировки из предыдущего места, где было сгенерировано исключение --- в System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () в System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (Task задача) в Rebus.Workers.ThreadPoolBased.ThreadPoolWorker.d__17.MoveNext ()

Через некоторое время, углубившись в эту проблему, мне удалось выполнить дизассемблирование реализации Rebus для класса MSMQ «MsmqTransport», и я смог увидеть, как Rebus взаимодействует с MSMQ, а также как свойство Extension заполняется двоичными данными Encoding.UTF8.GetBytes. .

Что мне не понятно, так это то, почему Encoding.UTF8.GetBytes(JsonConvert.Serialize(Dictionary<string,string>)) может привести к тому, что испорченный массив байтов.

Я считаю, что на эту реализацию Rebus MsmqTransport for MSMQ не может повлиять мой код, ни объект, который я отправляю в MSMQ, в котором он будет размещен в теле сообщения, а не в двоичном файле расширения или как я это настраиваю.

В качестве обходного пути, чтобы сохранить работоспособность всего решения, я реализовал службу, в которой просматривает сообщение из MSMQ, выполняет байты свойства Encoding.UTF8.GetString из Exteions, анализирует его, исправляет его в случае wierd символов и вытяните его обратно (исправный JSON) в свойстве Extension, затем удалите его из MSMQ и снова поместите его обратно в MSMQ, чтобы реальный процесс, использующий Rebus (подписчик), мог правильно его получить.

Есть ли способ, которым я могу выяснить, как Rebus портит двоичные данные, записанные в свойстве Extension сообщения MSMQ!?

Вот как я настраиваю Rebus в реализации Publisher:

Bus = Configure.With(activator)
                       .Logging(l => l.Trace())
                       .Options(o =>
                                {
                                    o.SimpleRetryStrategy(Config.ErrorQueue, Config.MaxDeliveryAttempts == 0 ? 3 : Config.MaxDeliveryAttempts);
                                    if (Config.EnableCompression)
                                        o.EnableCompression();
                                })
                       .Transport(t => t.UseMsmq(Config.PublisherQueue))
                       .Subscriptions(s => s.Register(c => SubscriptionStorage))
                       .Start();

Большое спасибо.

1 Ответ

0 голосов
/ 12 мая 2018

Звучит очень странно!

Как вы правильно поняли, способ, которым Ребус заполняет свойство Extension в MSMQ Message, не оставляет столько места для странных ошибок и забавного поведения, как то, что вы испытываете.

Однажды я использовал Rebus на сайте клиента, и в течение долгого времени все работало нормально, но внезапно, также без каких-либо изменений кода, странные вещи начали появляться в части Extension наших сообщений MSMQ, очень похоже на то, что вы видите.

После долгих размышлений и потрясений мы узнали, что наш заказчик нанял другую компанию, чтобы помочь им с общим мониторингом производительности и прочим, и одна из их инициатив заключалась в том, чтобы использовать свойство Extension сообщений MSMQ, возиться с заголовками Ребуса, тем самым ломая все.

Я не знаю, является ли это "стандартной практикой MSMQ", или почему они просто начнут портить наши сообщения, даже не спрашивая нас, будет ли это проблемой, но, может быть, это может быть чем-то похожим в вашем случае?

Если нет, у меня нет никаких улик.

...