[GitHub] [pulsar] 315157973 commented on a change in pull request #10240: [consumer] fix order guarantee for MultiTopicsConsumerImpl

[GitBox <gi...@apache.org>]

315157973 commented on a change in pull request #10240:
URL: https://github.com/apache/pulsar/pull/10240#discussion_r615524721



##########
File path: pulsar-client/src/main/java/org/apache/pulsar/client/impl/ConsumerImpl.java
##########
@@ -1050,15 +1043,15 @@ void messageReceived(MessageIdData messageId, int redeliveryCount, List<Long> ac
 
             // Enqueue the message so that it can be retrieved when application calls receive()
             // if the conf.getReceiverQueueSize() is 0 then discard message if no one is waiting for it.
-            // if asyncReceive is waiting then notify callback without adding to incomingMessages queue
             if (deadLetterPolicy != null && possibleSendToDeadLetterTopicMessages != null &&
                     redeliveryCount >= deadLetterPolicy.getMaxRedeliverCount()) {
                 possibleSendToDeadLetterTopicMessages.put((MessageIdImpl)message.getMessageId(),
                         Collections.singletonList(message));
             }
+            enqueueMessage(message);
             if (peekPendingReceive() != null) {
-                notifyPendingReceivedCallback(message, null);
-            } else if (enqueueMessageAndCheckBatchReceive(message) && hasPendingBatchReceive()) {
+                notifyPendingReceivedCallback(incomingMessages.poll(), null);

Review comment:
       If it is to be lock-free, I suggest to use executorProvider, the logic of the same consumerId will be processed in the same thread. Then compare the impact of performance.
   
   If you want to lock, we only need to ensure that the thread safety of these two scenarios can reduce the scope of the lock.
   1) When the poll comes out and the message is empty, put it into the pendingQueue
   2) Judge the pendingQueue is empty, enter enqueueMessageAndCheckBatchReceive
   
   Your current logic still has thread safety issues. If only one thread is consuming, it may cause a message in the queue to never be consumed, and there is also a pending future in the pendingQueue. This situation will occur in the scene of the last message.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org