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

Decouple the TransportService and ClusterService #16872

Merged
merged 0 commits into from
Mar 10, 2016

Conversation

bleskes
Copy link
Contributor

@bleskes bleskes commented Feb 29, 2016

Currently, the cluster service is tightly coupled to the transport service by both managing node connections and requiring the bound address in order to create the local disco node. This commit introduces a new NodeConnectionsService which is in charge of node connection management and makes it possible to remove all network related calls from the cluster service. The local DiscoNode is now created by DiscoveryNodeService and is set both the cluster service and the transport service during node start up.

Closes #16788

Note that this simplifies constructing the InternalClusterService making a viable option for testing. I already moved some of its testing to a unit test. As a follow up, I will attempt removing all test implementations of ClusterService and move InternalClusterService to be the one and only ClusterService.

@bleskes
Copy link
Contributor Author

bleskes commented Feb 29, 2016

@s1monw I still want to add a unit test for the new NodeConnectionsService but I think we can start the review process and get feedback..

assert localNode == null || localNode.equals(event.state().nodes().localNode());
localNode = event.state().nodes().localNode();

// nocommit: this can be done in parallel using parallel stream but then we get the following permission
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@rmuir can you take a look at this nocommit - how big a worry is it that we now can't do parallel streams?

Copy link
Contributor

Choose a reason for hiding this comment

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

It is no concern at all, it only prevents deadlocks and performance issues :)

Don't use parallel streams with the default pool, specify a pool instead (in the same or child thread group):

http://blog.krecan.net/2014/03/18/how-to-specify-thread-pool-for-java-8-parallel-streams/

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for educating me. Creating a ForkJoinPool seems like an overkill here (especially as I can't find an easy way to reuse our ThreadPools). I'll leave it as is (and re-add orignal todo to parallelize it - we can still do it "old style" if we want).

@s1monw
Copy link
Contributor

s1monw commented Mar 1, 2016

left some intial review comments

@bleskes bleskes force-pushed the decouple_cluster_service_transport branch from 0a7ab96 to 7eb3724 Compare March 3, 2016 10:09
@bleskes
Copy link
Contributor Author

bleskes commented Mar 3, 2016

@s1monw I rebased, added a unit test and addressed the comments. I think it's ready for review..


void validateNodeConnected(DiscoveryNode node) {
assert nodeLocks.isHeldByCurrentThread(node) : "validateNodeConnected must be called under lock";
if (lifecycle.stoppedOrClosed()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

any chance that this method has only one return statement?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sure.

Copy link
Contributor

Choose a reason for hiding this comment

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

maybe combine all the empty ifs in a single one ?

@bleskes
Copy link
Contributor Author

bleskes commented Mar 7, 2016

@s1monw thanks for the feedback. I pushed some more commits and merged from master. I think the main discussion still open is regarding listeners. Sadly github folded it away - but please check my answer here

@s1monw
Copy link
Contributor

s1monw commented Mar 8, 2016

@s1monw thanks for the feedback. I pushed some more commits and merged from master. I think the main discussion still open is regarding listeners. Sadly github folded it away - but please check my answer here

I agree with your plan here lets fix it in several steps and be explicit for now...

@s1monw
Copy link
Contributor

s1monw commented Mar 9, 2016

lets go with what we have I added some minors but LGTM otherwise, it's progress

@bleskes
Copy link
Contributor Author

bleskes commented Mar 9, 2016

@s1monw thx. pushed another commit

@s1monw
Copy link
Contributor

s1monw commented Mar 10, 2016

LGTM thanks @bleskes

@bleskes bleskes closed this Mar 10, 2016
@bleskes bleskes force-pushed the decouple_cluster_service_transport branch from 54d6a90 to cd12241 Compare March 10, 2016 10:52
bleskes added a commit to bleskes/elasticsearch that referenced this pull request Mar 10, 2016
Currently, the cluster service is tightly coupled to the transport service by both managing node connections and requiring the bound address in order to create the local disco node. This commit introduces a new NodeConnectionsService which is in charge of node connection management and makes it possible to remove all network related calls from the cluster service. The local DiscoNode is now created by DiscoveryNodeService and is set both the cluster service and the transport service during node start up.

Closes elastic#16788
Closes elastic#16872
@bleskes bleskes merged commit cd12241 into elastic:master Mar 10, 2016
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