You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by GitBox <gi...@apache.org> on 2022/09/28 06:34:01 UTC

[GitHub] [pulsar-client-go] wolfstudy opened a new pull request, #853: Parameterize the reconnection option

wolfstudy opened a new pull request, #853:
URL: https://github.com/apache/pulsar-client-go/pull/853

   Signed-off-by: xiaolongran <xi...@tencent.com>
   
   
   Fixes #851
   
   ### Motivation
   
   As  #851 said, the reconnection strategy in the default reconnection logic is not universal. In different usage scenarios, we better allow users to customize the reconnection strategy.
   
   ### Modifications
   
   Exposed `BackoffPolicy` in Producer and Consumer


-- 
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: commits-unsubscribe@pulsar.apache.org

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

[GitHub] [pulsar-client-go] frankjkelly commented on pull request #853: Parameterize the reconnection option

Posted by GitBox <gi...@apache.org>.
frankjkelly commented on PR #853:
URL: https://github.com/apache/pulsar-client-go/pull/853#issuecomment-1260812367

   
   > Yes, this is where the current Go SDK design is worth optimizing. In the Go SDK, we implemented the reconnect logic to the Producer side and the Consumer side respectively, and did not abstract a unified reconnect logic at the Client level. This leads to the Backoff strategy, we can only divide it into ProducerOptions and ConsumerOptions. In the follow-up, I think we should refactor here and abstract the logic of reconnect to the client side, which is more reasonable
   
   Thanks - sounds good - this is fine for our use-case as is


-- 
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: commits-unsubscribe@pulsar.apache.org

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

[GitHub] [pulsar-client-go] codelipenghui merged pull request #853: Parameterize the reconnection option

Posted by GitBox <gi...@apache.org>.
codelipenghui merged PR #853:
URL: https://github.com/apache/pulsar-client-go/pull/853


-- 
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: commits-unsubscribe@pulsar.apache.org

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

[GitHub] [pulsar-client-go] wolfstudy commented on pull request #853: Parameterize the reconnection option

Posted by GitBox <gi...@apache.org>.
wolfstudy commented on PR #853:
URL: https://github.com/apache/pulsar-client-go/pull/853#issuecomment-1260452196

   cc @frankjkelly PTAL


-- 
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: commits-unsubscribe@pulsar.apache.org

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

[GitHub] [pulsar-client-go] wolfstudy commented on pull request #853: Parameterize the reconnection option

Posted by GitBox <gi...@apache.org>.
wolfstudy commented on PR #853:
URL: https://github.com/apache/pulsar-client-go/pull/853#issuecomment-1260753669

   > LGTM - just confirming that the backoff will be on both the consumer and producer config (it was a little confusing to me as in the Java library it is solely on the client https://github.com/apache/pulsar/blob/31203c3952dfb82057ac1fbee4efc10682a5570b/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ClientBuilderImpl.java#L319-L323 )
   > 
   > (And also thanks so much for the quick turnaround)
   
   Yes, this is where the current Go SDK design is worth optimizing. In the Go SDK, we implemented the reconnect logic to the Producer side and the Consumer side respectively, and did not abstract a unified reconnect logic at the Client level. This leads to the Backoff strategy, we can only divide it into ProducerOptions and ConsumerOptions. In the follow-up, I think we should refactor here and abstract the logic of reconnect to the client side, which is more reasonable


-- 
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: commits-unsubscribe@pulsar.apache.org

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