Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved Connection Count server select strategy #15975

Merged

Conversation

sreemanamala
Copy link
Contributor

@sreemanamala sreemanamala commented Feb 27, 2024

Fixes #XXXX.

Description

Updated the Direct Druid Client so as to make Connection Count Server Selector Strategy work more efficiently.
If creating connection to a node is slow, then that slowness wouldn't be accounted for if we count the open connections after sending the request. So we increment the counter and then send the request.

Fixed the bug ...

Currently if a connection of server is blocked in creating a future job to run the query, it is not being counted resulting in the selector strategy allotting a new connection to same server.
Fixed this behaviour by incrementing the connection count prior to the start of future.

Release note


Key changed/added classes in this PR
  • DirectDruidClient
  • DirectDruidClientTest

This PR has:

  • been self-reviewed.
  • added documentation for new or modified features or behaviors.
  • a release note entry in the PR description.
  • added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
  • added or updated version, license, or notice information in licenses.yaml
  • added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
  • added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
  • added integration tests.
  • been tested in a test Druid cluster.

Copy link
Contributor

@abhishekagarwal87 abhishekagarwal87 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The description could use some clarity. If creating connection to a node is slow, then that slowness wouldn't be accounted for if we count the open connections after sending the request. So we increment the counter and then send the request.

Comment on lines 507 to 512
catch (RuntimeException e) {
if (openConnections.get() > 0) {
openConnections.getAndDecrement();
}
throw e;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be moved to after httpClient.go call. Also, why not decrement the counter for any exception and why is there a check on get() > 0

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added just to be on safe side, But it will never happen. Will remove the condition.

Comment on lines 149 to 155
EasyMock.expect(
httpClient.go(
EasyMock.capture(capturedRequest),
EasyMock.<HttpResponseHandler>anyObject(),
EasyMock.anyObject(Duration.class)
)
)
httpClient.go(
EasyMock.capture(capturedRequest),
EasyMock.<HttpResponseHandler>anyObject(),
EasyMock.anyObject(Duration.class)
)
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This re-formatting shouldn't have happened. Are you using a different checkstyle?

@@ -427,4 +431,47 @@ public void testQueryTimeoutFromFuture()
Assert.assertEquals(hostName, actualException.getHost());
EasyMock.verify(httpClient);
}

@Test
public void testRuntimeException() throws JsonProcessingException
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is too generic test name. I would suggest testConnectionCountAfterException

public void testRuntimeException() throws JsonProcessingException
{
ObjectMapper mockObjectMapper = EasyMock.createMock(ObjectMapper.class);
EasyMock.expect(mockObjectMapper.writeValueAsBytes(EasyMock.anyObject()))
Copy link
Contributor

@abhishekagarwal87 abhishekagarwal87 Mar 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lets intercept this call only when an object of type query is being serialized.

@abhishekagarwal87 abhishekagarwal87 merged commit 820febf into apache:master Mar 4, 2024
82 of 83 checks passed
@sreemanamala sreemanamala deleted the err-cnt-server-select-strategy branch March 13, 2024 01:38
@adarshsanjeev adarshsanjeev added this to the 30.0.0 milestone May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants