У нас есть структура, которую мы конвертируем в байтовый массив и упаковываем в свойство расширения MSMQ. Одним из значений в структуре является значение TimeToDelay. Мы перебираем полученные сообщения, ища сообщение со значением TimeToDelay + comingTime меньше текущего времени. По сути, было ли сообщение в очереди хотя бы TimeToDelay. Если это так, мы извлекаем сообщение и обрабатываем его, а не FIFO. Я сталкивался с ситуацией, когда клиент помещал очередь в загрузку, и некоторые из массивов расширенных байтов были получены как мусор. Массив байтов должен выглядеть примерно так:
4A-BF-CE-DB-EB-F3-29-41-BE-37-A5-27-1F-1F-3 C -36- 03-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
Но вместо этого он выглядит так:
53 -6E-67-3D-48-64-72-2A-6E-6F-74-78-64-65-74-65-63-74-3D-54-72-75-65-2A-63-74 -72-6 C -67-75-69-64-3D-31-35-37-34-36-35-37-39-37-37-2A-61-70-70-49-64- 3D-31-32-35-36-39-35-2A-6E-6F-64-65-69-64-3D-31-37-32-33-34-35-35-36
Я прочитал все, что MSMQ не может быть поврежден, но я не вижу другого объяснения. Сообщение записывается как первый байтовый массив каждый раз. Я также читал, что MSMQ всегда следует читать FIFO, но без объяснения того, почему или каков будет побочный эффект, если мы не