You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Bill Burcham <bi...@gmail.com> on 2019/11/18 21:48:07 UTC
[DISCUSS] Move TcpServer and friends to new geode-tcp-server module
Dear Geode,
In support of the Membership modularization efforts
https://cwiki.apache.org/confluence/display/GEODE/Move+membership+code+to+a+separate+gradle+sub-project,
we would like to move the types in the
org.apache.geode.distributed.internal.tcpserver package (i.e. the TcpServer
class and related types) into a separate module in order to eliminate
dependencies on geode-core.
The membership subsystem is dependent on this group of types, which in turn
are (were) highly-dependent on geode-core. We have been systematically
eliminating dependencies from these types to geode-core as part of
https://issues.apache.org/jira/browse/GEODE-7343 _TcpServer should not
depend on geode-core_ The final sub-task on that ticket puts TcpServer and
related types into its own separate module.
The proposed module would be called "geode-tcp-server" and would contain
TcpServer and the other types in the
org.apache.geode.distributed.internal.tcpserver package.
Your feedback is welcomed and appreciated.
Your Friend,
Bill
Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server module
Posted by Bill Burcham <bi...@gmail.com>.
Thanks for the feedback. We have rough consensus for the new module so we
will make it so.
On Mon, Nov 18, 2019 at 5:34 PM Joris Melchior <jm...@pivotal.io> wrote:
> +1
>
> On Mon, Nov 18, 2019 at 6:22 PM Owen Nichols <on...@pivotal.io> wrote:
>
> > +1
> >
> > > On Nov 18, 2019, at 3:00 PM, Nabarun Nag <nn...@pivotal.io> wrote:
> > >
> > > +1
> > >
> > > On Mon, Nov 18, 2019 at 2:21 PM Udo Kohlmeyer <ud...@apache.com> wrote:
> > >
> > >> Thank you for this Bill,
> > >>
> > >> I must admit that I'm starting to get a feeling of "scope creep"
> here..
> > >> I understand that all efforts to "modularize" membership would require
> > >> some form of peripheral decoupling.
> > >>
> > >> BUT
> > >>
> > >> I'm starting to get concerned that we are hitting a rabbit hole
> > >> scenario. Maybe this is normal for an effort of this manner, BUT, I
> > >> would like to urge that we start discussing/proposing other
> > >> modulizations, like, Serialization and now TCP communications as real
> > >> modules with own proposals and with their own merit.
> > >>
> > >> YES, I understand this is minimal touch modulizations, but I'm
> concerned
> > >> that we are doing work under the incorrect banner. Just enough to
> > >> complete one "piece of it", but possibly a rework, of the module
> because
> > >> of the "good enough" approach we take.
> > >>
> > >> Maybe we are discovering that there is some pre-work that needed to
> have
> > >> been completed before the whole membership modularization effort was
> > >> started.. And maybe this is the time where we need to take a step
> back,
> > >> look at this from a higher perspective and decide if membership is
> > >> really still the priority here with serialization and transport
> > >> (TCPServer) being a side-effect.
> > >>
> > >> For this reason alone I vote: *-0 *on this matter.. (it is only a
> little
> > >> better than -1)
> > >>
> > >> --Udo
> > >>
> > >> On 11/18/19 1:48 PM, Bill Burcham wrote:
> > >>> Dear Geode,
> > >>>
> > >>> In support of the Membership modularization efforts
> > >>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+membership+code+to+a+separate+gradle+sub-project
> > >> ,
> > >>> we would like to move the types in the
> > >>> org.apache.geode.distributed.internal.tcpserver package (i.e. the
> > >> TcpServer
> > >>> class and related types) into a separate module in order to eliminate
> > >>> dependencies on geode-core.
> > >>>
> > >>> The membership subsystem is dependent on this group of types, which
> in
> > >> turn
> > >>> are (were) highly-dependent on geode-core. We have been
> systematically
> > >>> eliminating dependencies from these types to geode-core as part of
> > >>> https://issues.apache.org/jira/browse/GEODE-7343 _TcpServer should
> not
> > >>> depend on geode-core_ The final sub-task on that ticket puts
> TcpServer
> > >> and
> > >>> related types into its own separate module.
> > >>>
> > >>> The proposed module would be called "geode-tcp-server" and would
> > contain
> > >>> TcpServer and the other types in the
> > >>> org.apache.geode.distributed.internal.tcpserver package.
> > >>>
> > >>> Your feedback is welcomed and appreciated.
> > >>>
> > >>> Your Friend,
> > >>> Bill
> > >>>
> > >>
> >
> >
>
> --
> *Joris Melchior *
> CF Engineering
> Pivotal Toronto
> 416 877 5427
>
> “Programs must be written for people to read, and only incidentally for
> machines to execute.” – *Hal Abelson*
> <https://en.wikipedia.org/wiki/Hal_Abelson>
>
Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server module
Posted by Joris Melchior <jm...@pivotal.io>.
+1
On Mon, Nov 18, 2019 at 6:22 PM Owen Nichols <on...@pivotal.io> wrote:
> +1
>
> > On Nov 18, 2019, at 3:00 PM, Nabarun Nag <nn...@pivotal.io> wrote:
> >
> > +1
> >
> > On Mon, Nov 18, 2019 at 2:21 PM Udo Kohlmeyer <ud...@apache.com> wrote:
> >
> >> Thank you for this Bill,
> >>
> >> I must admit that I'm starting to get a feeling of "scope creep" here..
> >> I understand that all efforts to "modularize" membership would require
> >> some form of peripheral decoupling.
> >>
> >> BUT
> >>
> >> I'm starting to get concerned that we are hitting a rabbit hole
> >> scenario. Maybe this is normal for an effort of this manner, BUT, I
> >> would like to urge that we start discussing/proposing other
> >> modulizations, like, Serialization and now TCP communications as real
> >> modules with own proposals and with their own merit.
> >>
> >> YES, I understand this is minimal touch modulizations, but I'm concerned
> >> that we are doing work under the incorrect banner. Just enough to
> >> complete one "piece of it", but possibly a rework, of the module because
> >> of the "good enough" approach we take.
> >>
> >> Maybe we are discovering that there is some pre-work that needed to have
> >> been completed before the whole membership modularization effort was
> >> started.. And maybe this is the time where we need to take a step back,
> >> look at this from a higher perspective and decide if membership is
> >> really still the priority here with serialization and transport
> >> (TCPServer) being a side-effect.
> >>
> >> For this reason alone I vote: *-0 *on this matter.. (it is only a little
> >> better than -1)
> >>
> >> --Udo
> >>
> >> On 11/18/19 1:48 PM, Bill Burcham wrote:
> >>> Dear Geode,
> >>>
> >>> In support of the Membership modularization efforts
> >>>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Move+membership+code+to+a+separate+gradle+sub-project
> >> ,
> >>> we would like to move the types in the
> >>> org.apache.geode.distributed.internal.tcpserver package (i.e. the
> >> TcpServer
> >>> class and related types) into a separate module in order to eliminate
> >>> dependencies on geode-core.
> >>>
> >>> The membership subsystem is dependent on this group of types, which in
> >> turn
> >>> are (were) highly-dependent on geode-core. We have been systematically
> >>> eliminating dependencies from these types to geode-core as part of
> >>> https://issues.apache.org/jira/browse/GEODE-7343 _TcpServer should not
> >>> depend on geode-core_ The final sub-task on that ticket puts TcpServer
> >> and
> >>> related types into its own separate module.
> >>>
> >>> The proposed module would be called "geode-tcp-server" and would
> contain
> >>> TcpServer and the other types in the
> >>> org.apache.geode.distributed.internal.tcpserver package.
> >>>
> >>> Your feedback is welcomed and appreciated.
> >>>
> >>> Your Friend,
> >>> Bill
> >>>
> >>
>
>
--
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427
“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>
Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server
module
Posted by Owen Nichols <on...@pivotal.io>.
+1
> On Nov 18, 2019, at 3:00 PM, Nabarun Nag <nn...@pivotal.io> wrote:
>
> +1
>
> On Mon, Nov 18, 2019 at 2:21 PM Udo Kohlmeyer <ud...@apache.com> wrote:
>
>> Thank you for this Bill,
>>
>> I must admit that I'm starting to get a feeling of "scope creep" here..
>> I understand that all efforts to "modularize" membership would require
>> some form of peripheral decoupling.
>>
>> BUT
>>
>> I'm starting to get concerned that we are hitting a rabbit hole
>> scenario. Maybe this is normal for an effort of this manner, BUT, I
>> would like to urge that we start discussing/proposing other
>> modulizations, like, Serialization and now TCP communications as real
>> modules with own proposals and with their own merit.
>>
>> YES, I understand this is minimal touch modulizations, but I'm concerned
>> that we are doing work under the incorrect banner. Just enough to
>> complete one "piece of it", but possibly a rework, of the module because
>> of the "good enough" approach we take.
>>
>> Maybe we are discovering that there is some pre-work that needed to have
>> been completed before the whole membership modularization effort was
>> started.. And maybe this is the time where we need to take a step back,
>> look at this from a higher perspective and decide if membership is
>> really still the priority here with serialization and transport
>> (TCPServer) being a side-effect.
>>
>> For this reason alone I vote: *-0 *on this matter.. (it is only a little
>> better than -1)
>>
>> --Udo
>>
>> On 11/18/19 1:48 PM, Bill Burcham wrote:
>>> Dear Geode,
>>>
>>> In support of the Membership modularization efforts
>>>
>> https://cwiki.apache.org/confluence/display/GEODE/Move+membership+code+to+a+separate+gradle+sub-project
>> ,
>>> we would like to move the types in the
>>> org.apache.geode.distributed.internal.tcpserver package (i.e. the
>> TcpServer
>>> class and related types) into a separate module in order to eliminate
>>> dependencies on geode-core.
>>>
>>> The membership subsystem is dependent on this group of types, which in
>> turn
>>> are (were) highly-dependent on geode-core. We have been systematically
>>> eliminating dependencies from these types to geode-core as part of
>>> https://issues.apache.org/jira/browse/GEODE-7343 _TcpServer should not
>>> depend on geode-core_ The final sub-task on that ticket puts TcpServer
>> and
>>> related types into its own separate module.
>>>
>>> The proposed module would be called "geode-tcp-server" and would contain
>>> TcpServer and the other types in the
>>> org.apache.geode.distributed.internal.tcpserver package.
>>>
>>> Your feedback is welcomed and appreciated.
>>>
>>> Your Friend,
>>> Bill
>>>
>>
Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server module
Posted by Nabarun Nag <nn...@pivotal.io>.
+1
On Mon, Nov 18, 2019 at 2:21 PM Udo Kohlmeyer <ud...@apache.com> wrote:
> Thank you for this Bill,
>
> I must admit that I'm starting to get a feeling of "scope creep" here..
> I understand that all efforts to "modularize" membership would require
> some form of peripheral decoupling.
>
> BUT
>
> I'm starting to get concerned that we are hitting a rabbit hole
> scenario. Maybe this is normal for an effort of this manner, BUT, I
> would like to urge that we start discussing/proposing other
> modulizations, like, Serialization and now TCP communications as real
> modules with own proposals and with their own merit.
>
> YES, I understand this is minimal touch modulizations, but I'm concerned
> that we are doing work under the incorrect banner. Just enough to
> complete one "piece of it", but possibly a rework, of the module because
> of the "good enough" approach we take.
>
> Maybe we are discovering that there is some pre-work that needed to have
> been completed before the whole membership modularization effort was
> started.. And maybe this is the time where we need to take a step back,
> look at this from a higher perspective and decide if membership is
> really still the priority here with serialization and transport
> (TCPServer) being a side-effect.
>
> For this reason alone I vote: *-0 *on this matter.. (it is only a little
> better than -1)
>
> --Udo
>
> On 11/18/19 1:48 PM, Bill Burcham wrote:
> > Dear Geode,
> >
> > In support of the Membership modularization efforts
> >
> https://cwiki.apache.org/confluence/display/GEODE/Move+membership+code+to+a+separate+gradle+sub-project
> ,
> > we would like to move the types in the
> > org.apache.geode.distributed.internal.tcpserver package (i.e. the
> TcpServer
> > class and related types) into a separate module in order to eliminate
> > dependencies on geode-core.
> >
> > The membership subsystem is dependent on this group of types, which in
> turn
> > are (were) highly-dependent on geode-core. We have been systematically
> > eliminating dependencies from these types to geode-core as part of
> > https://issues.apache.org/jira/browse/GEODE-7343 _TcpServer should not
> > depend on geode-core_ The final sub-task on that ticket puts TcpServer
> and
> > related types into its own separate module.
> >
> > The proposed module would be called "geode-tcp-server" and would contain
> > TcpServer and the other types in the
> > org.apache.geode.distributed.internal.tcpserver package.
> >
> > Your feedback is welcomed and appreciated.
> >
> > Your Friend,
> > Bill
> >
>
Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server
module
Posted by Udo Kohlmeyer <ud...@apache.com>.
Thank you for this Bill,
I must admit that I'm starting to get a feeling of "scope creep" here..
I understand that all efforts to "modularize" membership would require
some form of peripheral decoupling.
BUT
I'm starting to get concerned that we are hitting a rabbit hole
scenario. Maybe this is normal for an effort of this manner, BUT, I
would like to urge that we start discussing/proposing other
modulizations, like, Serialization and now TCP communications as real
modules with own proposals and with their own merit.
YES, I understand this is minimal touch modulizations, but I'm concerned
that we are doing work under the incorrect banner. Just enough to
complete one "piece of it", but possibly a rework, of the module because
of the "good enough" approach we take.
Maybe we are discovering that there is some pre-work that needed to have
been completed before the whole membership modularization effort was
started.. And maybe this is the time where we need to take a step back,
look at this from a higher perspective and decide if membership is
really still the priority here with serialization and transport
(TCPServer) being a side-effect.
For this reason alone I vote: *-0 *on this matter.. (it is only a little
better than -1)
--Udo
On 11/18/19 1:48 PM, Bill Burcham wrote:
> Dear Geode,
>
> In support of the Membership modularization efforts
> https://cwiki.apache.org/confluence/display/GEODE/Move+membership+code+to+a+separate+gradle+sub-project,
> we would like to move the types in the
> org.apache.geode.distributed.internal.tcpserver package (i.e. the TcpServer
> class and related types) into a separate module in order to eliminate
> dependencies on geode-core.
>
> The membership subsystem is dependent on this group of types, which in turn
> are (were) highly-dependent on geode-core. We have been systematically
> eliminating dependencies from these types to geode-core as part of
> https://issues.apache.org/jira/browse/GEODE-7343 _TcpServer should not
> depend on geode-core_ The final sub-task on that ticket puts TcpServer and
> related types into its own separate module.
>
> The proposed module would be called "geode-tcp-server" and would contain
> TcpServer and the other types in the
> org.apache.geode.distributed.internal.tcpserver package.
>
> Your feedback is welcomed and appreciated.
>
> Your Friend,
> Bill
>
Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server module
Posted by Dan Smith <ds...@pivotal.io>.
+1
-Dan
On Mon, Nov 18, 2019 at 1:48 PM Bill Burcham <bi...@gmail.com> wrote:
> Dear Geode,
>
> In support of the Membership modularization efforts
>
> https://cwiki.apache.org/confluence/display/GEODE/Move+membership+code+to+a+separate+gradle+sub-project
> ,
> we would like to move the types in the
> org.apache.geode.distributed.internal.tcpserver package (i.e. the TcpServer
> class and related types) into a separate module in order to eliminate
> dependencies on geode-core.
>
> The membership subsystem is dependent on this group of types, which in turn
> are (were) highly-dependent on geode-core. We have been systematically
> eliminating dependencies from these types to geode-core as part of
> https://issues.apache.org/jira/browse/GEODE-7343 _TcpServer should not
> depend on geode-core_ The final sub-task on that ticket puts TcpServer and
> related types into its own separate module.
>
> The proposed module would be called "geode-tcp-server" and would contain
> TcpServer and the other types in the
> org.apache.geode.distributed.internal.tcpserver package.
>
> Your feedback is welcomed and appreciated.
>
> Your Friend,
> Bill
>