Просмотрите сообщение перед получением

Я новичок в Azure и изучаю автобусы обслуживания и ремонта за последние пару недель.

Я пытаюсь прочитать сообщения из очереди служебной шины Azure. Метод получения QueueClient извлечет сообщение из очереди, чего я не хочу делать изначально. Поэтому я просматриваю все сообщения в очереди по одному в цикле while, используя метод Peek (). Затем я сравниваю идентификатор корреляции сообщения с идентификатором корреляции, который я внутренне поддерживаю в локальной таблице БД.

Только если идентификатор корреляции совпадает, я получаю сообщение. Но, чтобы получить сообщение с помощью messageSequencenumber, я узнал, что мне нужно сначала отложить сообщение, получить идентификатор сообщения, хранящийся в списке или что-то еще, а затем использовать метод QueueClient Receive () для получения сообщений и, наконец, пометить сообщение как полный.

Но поскольку я просматриваю сообщения с помощью Peek (), это не позволяет мне отложить сообщение. Я застрял здесь, получая сообщение с помощью messageId.

Также я не могу просто заполнить сообщение до получения.

Не могли бы вы предложить какие-нибудь способы добиться этого?

BrokeredMessage message = new BrokeredMessage();
message = null;

while ((message = reader.Peek()) != null && row_count > 0)
{

List<long> deferredMessageReceipts = new List<long>(); 

// Read Ping results table to get the rows with no msg_recv_ts

logobj.Categories.Clear();
logobj.Categories.Add("INFO");
logobj.Message = "Reading ! Message: " + " Correlation ID:" +      message.CorrelationId;
Logger.Write(logobj);

if (message != null)
{

if (PRTA_rows.Corr_id == message.CorrelationId) //compare correlation ids 
 {
  DateTime ping_recv_ts = DateTime.Now;
  logobj.Categories.Clear();
                            logobj.Categories.Add("INFO");

 string messageBody = message.GetBody<string>();
 logobj.Message = "Ack Message Found ! Message Body: " + messageBody + "       Correlation ID:" + message.CorrelationId;
 Logger.Write(logobj);
 string msg_type = "PING_ACK";
 logobj.Categories.Clear();
                            logobj.Categories.Add("INFO");
 logobj.Message = "Marking Message as complete...";
 Logger.Write(logobj);


 // Deferring a message
 message.Defer(); // Getting error here "The operation cannot be completed      because the ReceiveContext is null."

 long msg_seq_nbr=message.SequenceNumber;

 reader.Receive(msg_seq_nbr); // This operation is not possible without    deferring the message.

 message.Complete();

   }


   }
   }  // End while browsing messages.

person CSharpBeginner    schedule 09.04.2015    source источник
comment
Какая связь между сообщением в очереди и локальной базой данных? Я пытаюсь понять, почему вам нужно искать конкретное сообщение для обработки, а не просто последовательно обрабатывать сообщения из очереди по мере их получения (в конце концов, это очередь).   -  person Brendan Green    schedule 10.04.2015
comment
Просматриваемая мной очередь - это обычная очередь, используемая несколькими приложениями. Поэтому я не хочу получать другие сообщения. Когда я отправляю сообщение в очередь, я прикрепляю уникальный идентификатор к сообщению и отслеживаю его в таблице БД. Поэтому, когда я читаю очередь, ищу все сообщения с помощью метода PEEK, чтобы узнать, существует ли мое сообщение в очереди. Если я нашел свое сообщение, я его получаю. Если я начну получать каждое сообщение последовательно, это увеличит счетчик доставки. Поэтому я использую peek (), чтобы посмотреть, что такое guid, и получить сообщение, только если это мое сообщение,   -  person CSharpBeginner    schedule 10.04.2015
comment
Кажется, что невозможно просмотреть и завершить сообщение без получения. Рассмотрите возможность изменения вашей архитектуры, чтобы использовать несколько очередей для разных типов сообщений. Или используйте тему и несколько подписчиков с фильтрами по CorrelationId.   -  person Vadim K.    schedule 10.04.2015
comment
Вот что у меня получилось .. Но шрифт знаю точно .. Не могли бы вы подтвердить, пожалуйста .. возможно это или нет ..   -  person CSharpBeginner    schedule 13.04.2015


Ответы (1)


Я думаю, вам следует пересмотреть свой дизайн, поскольку это не то, как вы обычно используете систему очередей. Они используются, когда вам нужна временная развязка, балансировка нагрузки и используются в порядке очереди.

Вы можете рассмотреть возможность использования тем Servicebus и иметь подписчиков для каждого приложения. Темы похожи на очереди, но используют модель Pub \ Sub. Вы можете использовать фильтры в разделе Topic \ Subscription, чтобы направлять сообщения в правильную подписку. Все приложения будут «публиковаться» в одной теме, и у вас будет подписка для каждого приложения.

person Mikee    schedule 20.05.2015