PavelZeger commented on PR #1490:
URL: 
https://github.com/apache/pulsar-client-go/pull/1490#issuecomment-4412631396

   > Hi @PavelZeger, could you follow up on the Java client logic?
   
    Sure, @nodece. 
   I pushed an update that takes the parts of your proposal we can apply 
without breaking the existing API:                                              
                                                    
                                                                                
                                                         
    **What's done now**                                                         
                                                        
                                                                                
                                                         
     1. **Backoff cap no longer ends retries or fires the listener.** Dropped 
the `IsMaxBackoffReached` check from `reconnectToBroker`.  The consumer now 
keeps retrying forever at the capped delay, just like Java's 
`ConnectionHandler.reconnectLater()`.                 
     2. **Non-retriable errors are detected and reported.** Added a check for 
the consumer-relevant errors that Java treats as non-retriable: 
`AuthorizationError`, `TopicNotFound`, `TopicTerminatedError`, 
`SubscriptionNotFound`, `IncompatibleSchema`, `ConsumerBusy`, 
`InvalidTopicName`, `ConsumerAssignError`, `NotAllowedError`. When the broker 
returns one of these, the listener fires with the error and the retry loop 
stops - same idea as Java's `connectionFailed()`.                               
            
                                                                                
                                                         
   **What I left for later**                   
                                                                                
                                                         
     3. I kept `MaxReconnectToBroker` as an opt-in cap on runtime reconnects. 
Issue #1481 specifically asks for a way to stop the consumer after a bounded 
number of failed reconnects, so removing it would break users who already set 
it. Can revisit if maintainers want it removed.
     4. Applying `MaxReconnectToBroker` (or a new `LookupTimeout`) at initial 
subscribe is a different code path. I'd rather file it as a follow-up issue so 
it gets its own focused review.                                                 
                              
                                                                                
                                                         
   Does this work for you? If you want me to go further on 3 or 4 in this PR, 
let me know — otherwise I'll open a follow-up for 4 after this PR.              
     
   
     Sources:                                                                   
                                                         
     - 
https://raw.githubusercontent.com/apache/pulsar/master/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ConnectionHandler
     .java                                                                      
                                                         
     - 
https://raw.githubusercontent.com/apache/pulsar/master/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ConsumerImpl.java
     - 
https://raw.githubusercontent.com/apache/pulsar/master/pulsar-common/src/main/java/org/apache/pulsar/common/util/Backoff.java
     
     - 
https://raw.githubusercontent.com/apache/pulsar/master/pulsar-client-api/src/main/java/org/apache/pulsar/client/api/PulsarClientEx
     ception.java 


-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to