Cluster should not expose its internal fields

Description

It is currently possible to access a Cluster's internal manager field, and that is done in several places in our code.

While this works in most cases, it is error-prone and will not work properly under at least one identified situation: when a DelegatingCluster is in use and one calls AbstractSession.checkNotInEventLoopGroup() on a Session returned by that cluster.

A simple and trivial fix would be to amend AbstractSession.checkNotInEventLoopGroup() so that it does not access the field directly, but a better solution would be to encapsulate that field.

Among other benefits, it would allow us to simplify a lot the implementation of DelegatingCluster.

Environment

None

Pull Requests

None

Activity

Show:
Olivier Michallat
June 20, 2017, 3:09 PM

It is currently possible to access a DelegatingCluster's internal manager field

Could you give examples of how this can be done through the public API?

Alexandre Dutra
June 20, 2017, 5:32 PM
Edited

Sorry I was a bit too alarmist in my description. It turns out that the only really problematic place is AbstractSession.checkNotInEventLoopGroup(). All the other places could keep accessing the internal field.

However: by encapsulating this field, we not only make internal code more bullet-proof, but it also can simplify a lot the implementation of DelegatingCluster. It would basically boil down to the following:

Alexandre Dutra
January 23, 2018, 2:11 PM

This is now superseded by driver 4.0, closing.

Won't Do

Assignee

Unassigned

Reporter

Alexandre Dutra

Labels

None

PM Priority

None

Reproduced in

None

Affects versions

Fix versions

None

Pull Request

None

Doc Impact

None

Size

None

External issue ID

None

External issue ID

None

Priority

Major
Configure