title: Azure ServiceBus message reprocessing using MaxDeliveryCount
body: <p>I'm trying to use the ServiceBus subscriptions's MaxDeliveryCount for implementing retry of message processing. Not sure it's the best idea, but don't want to lose messages.</p>
  
  <p>Scenario: </p>
  
  <ol>
  <li>Having one topic, with two subscribers one sending (A) and the other
  (B) receiving messages, using Peek-Lock</li>
  <li>Both subscriptions have configured MaxDeliveryCount=10</li>
  <li>Both clients use 
  SubscriptionClient.ReceiveBatch(50,TimeSpan.FromMilliseconds(50)) to
      get the messages from the Queue</li>
  <li>A sends 5 messages, having payload "1", "2",..."5"</li>
  <li><p>The first messages ("1") fails to process on B and is marked as abandoned (BrokeredMessage.Abandon())</p>
  
  <p>Reason: for internal reasons, app can't process this message now.</p>
  
  <p>It's not yet BlackLettered since DeliveryCount &lt; MaxDeliveryCount)</p></li>
  <li>Next, since the message "1" previously failed, only one message is
  requested from, and it's expected to be message "1"
  SubscriptionClient.ReceiveBatch(1,TimeSpan.FromMilliseconds(50))</li>
  <li>After 2-3 repetitions of step 7, instead of receiving message "1",
  message "2" is received   Message "2" is also marked as Abandoned
  since message "1" is expected</li>
  <li><p>Then message "3" is received<br>
      Message "3" is also marked as Abandoned since message "1" is
      expected</p>
  
  <p>and so on.</p></li>
  </ol>
  
  <p>It seems, in this scenario, the SB is delivering the messages in a Round Robing manner.</p>
  
  <p>Is this the intended behavior of ServiceBus?</p>
  
  <p>I am aware about the existence of some debates whether SB guarantees ordered delivery or not. For the applications it's really important that messages are processed in the same order they are sent.</p>
  
  <p>Any ideas how reprocessing of message "1" could be performed until DeliveryCount reaches MaxDeliveryCount before processing the message "2"?</p>