Subject: [pgjdbc/pgjdbc] PR #3409: feat: add support for plugging in custom HostChooser

From: "kneeraj (@kneeraj)" <[email-masked]>
Date: Fri, 18 Oct 2024 12:08:39 +0000

### All Submissions:

* - [x] Have you followed the guidelines in our [Contributing](https://github.com/pgjdbc/pgjdbc/blob/master/CONTRIBUTING.md) document?
* - [x] Have you checked to ensure there aren't other open [Pull Requests](../../pulls) for the same update/change?

<!-- You can erase any parts of this template not applicable to your Pull Request. -->

### New Feature Submissions:

1. - [x] Does your submission pass tests?
2. - [x] Does `./gradlew styleCheck` pass ?
3. - [X] Have you added your new test classes to an existing test suite in alphabetical order?

### Changes to Existing Features:

* - [ ] Does this break existing behaviour? If so please explain.
* - [x] Have you added an explanation of what your changes do and why you'd like us to include them?
      [Github Issue](https://github.com/pgjdbc/pgjdbc/issues/3367) with details.
* - [x] Have you written new tests for your core changes, as applicable?
* - [x] Have you successfully run tests with your changes locally?

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Thu, 07 Nov 2024 08:16:31 +0000

Thank you for the draft, and sorry for the delay with the review. In general, it looks like a good start.

However, it looks like `GlobalHostStatusTracker` duplicates the logic of `registerFailure` and `registerSuccess`, so I would like to make the current host chooser a plugin, so should not rely on `GlobalHostStatusTracker.reportHostStatus` from `ConnectionFactoryImpl`.
In other words, currently the PR suggests a set of new APIs, however, it is not clear if the old balancer could be implemented as an external plugin that uses the new APIs only.

What do you think?

---

From: "kneeraj (@kneeraj)" <[email-masked]>
Date: Fri, 08 Nov 2024 04:56:14 +0000

> However, it looks like `GlobalHostStatusTracker` duplicates the logic of `registerFailure` and `registerSuccess`, so I would like to make the current host chooser a plugin, so should not rely on `GlobalHostStatusTracker.reportHostStatus` from `ConnectionFactoryImpl`. In other words, currently the PR suggests a set of new APIs, however, it is not clear if the old balancer could be implemented as an external plugin that uses the new APIs only.
> 
> What do you think?

Thank you for starting the review @vlsi .

I see your point about duplicating the logic. If I understand correctly the current hostchoosers i.e SingleHostChooser and MultiHostChooser should track the host status through `register*` methods only and the GlobalHostStatusTracker's majority logic should go inside these two inbuilt HostChoosers.
Let me know if I have understood correctly and if I should try to refactor accordingly.

---

From: "robert-mirzakhanian (@robert-mirzakhanian)" <[email-masked]>
Date: Wed, 28 May 2025 12:40:09 +0000

Hi everyone! Just checking in to see if there are any updates on this PR. Is there anything I can do to help move it forward? Thanks!