Ws client can't receive any more messages when number of timed-out messages reaches receiverQueueSize

[hrsakai]

Ws proxy controls message-delivery to ws client by using pendingMessages.
pendingMessages increases when ws proxy sends a message to ws client and It decreases when ws client acks to ws proxy.
If pendingMessages reaches receiverQueueSize, ws proxy stops to send a message until ws client acks.
Even if a message times out(cause by ws client unack), pendingMessages doesn't decrease and ws proxy keeps waiting for ack.

Expected behavior

When a message times out, pendingMessages decreases.

Actual behavior

pendingMessages doesn't decrease.
So ws client can't receive any more messages when timed-out messages reaches receiverQueueSize.

Steps to reproduce

1. ws client connects to ws proxy url(ws:<hostname>/ws/consumer/persistent/...?ackTimeoutMillis=1000&receiverQueueSize=2&subscriptionType=Shared)
2. producer sends 2 messages.
3. ws client recieves 2 messages and not ack them.
4. ws client doesn't receive any more messages until ws client reconnects even if ackTimeoutMillis(1000ms) passes.

System configuration

Pulsar version: 1.22.1 and 2.2.1

pendingMessages
https://github.com/apache/pulsar/blob/branch-2.2/pulsar-websocket/src/main/java/org/apache/pulsar/websocket/ConsumerHandler.java#L75

[jiazhai]

As the document mentioned, In receive, it dispatches further messages after ack.

It seems be working as designed.

/**
 *
 * WebSocket end-point url handler to handle incoming receive and acknowledge requests.
 * <p>
 * <b>receive:</b> socket-proxy keeps pushing messages to client by writing into session. However, it dispatches N
 * messages at any point and after that on acknowledgement from client it dispatches further messages. <br/>
 * <b>acknowledge:</b> it accepts acknowledgement for a given message from client and send it to broker. and for next
 * action it notifies receive to dispatch further messages to client.
 * </P>
 *
 */

[jiazhai]

@merlimat @rdhabalia Do you think we need break the original behaviour?
Seems the logic of ConsumerHandler.java will changed a little for it.

[sijie]

close this as it seems to be not a problem.