Re: [PROPOSAL] Deprecating DistributedSystem

[John Blum]

Correcting (for Geode) and adding to the o.a.g.cache.execute.FunctionService
 reference...

http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/execute/FunctionService.html#onMember-org.apache.geode.distributed.DistributedMember-
http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/execute/FunctionService.html#onMembers-java.util.Set-


Also, regarding...

*> Likewise, the configuration properties will be accessible via the
(also currently @Experimental) ClusterConfigurationService interface,
accessible via GfshCommand::getConfigurationService.*

As an application developer, framework developer or even tool developer,
why would I need, or even want to acquire the ClusterConfigurationService via
an instance of the GfshCommand class?  What does *Gfsh* have to do with my
application, framework or tool?


*> The context in which the findMember methods are useful is (as far as I
can tell) limited to commands being run on a locator.*

The point of view w.r.t. "context" described in this case is far too
narrow!  There is a far wider audience (and opportunity) out there than
just considering what Geode itself currently does or needs.  I implore the
entire Geode community to be thinking about the ecosystem when making what
seems like trivial decisions.


It would be unfortunate if the functionality exposed in
o.a.g.distributed.DistributedSystem moved to the o.a.g.distributed.
*internal*.DistributionManager class (all, or in part), or even the
o.a.g.cache.GemFireCache / Cache interface for that matter (more on this
below), since DistributionManager resides in what is deemed to be an
"internal" API and therefore is not subject to all the same change controls
as the current "public" API.

Although, I'd say Geode's current notion of "internal things" is highly
broken anyway since 1) some of the "internal" functionality is actually
needed/useful and/or ought to be public and 2) putting things in a package
named "internal" is not the proper way to "hide" things in Java.  Exposing
well-defined interfaces with proper extension points and using appropriate
access modifiers is.

DistributionManager is a good example of a class that 1) should be an
interface, 2) expose an SPI/API and 3) be pluggable.  Why shouldn't
distribution and messaging be configurable/extensible?  Geode's OOB
implementation is just another service provider implementation like any
other.  It's ironic that, "You may also register a membership listener with
the DistributionManager to receive notification of changes in membership"
when the class is "internal" yet such functionality would actually be
highly useful, especially in other tooling, but even in frameworks or
applications in some cases.

With regard to my earlier point above, arbitrarily shifting
DistributedSystem functions to other Geode components without consideration
for what the component is or ought to be concerned with is confusing to
users.  The required and overloaded use of DistributedSystem to create a
*Pool* on the client is a good example, where clients are hardly, if ever
concerned with being distributed in nature (though is technically possible
with Geode).  This is one reason why Geode's cache may not be the
appropriate place for certain functions given Geode's notion of a cache is
inconsistent with the industry accepted (dare I say "standard") terminology
in the first place, which, in Geode, is really a *Region*. Geode's cache is
more like a "*CacheManager" *to bind in other services, like
"distribution", to give a cache all its power (horizontal scalability, HA,
etc).  But certainly a cache does not need to be "distributed", which is
especially the case when employing "*near-caching*", often a client-side
concern and a very useful pattern in its own right.

Finally, where configuration is concerned, while I would generally prefer
to have a single interface to access system configuration, I also think it
would be highly valuable to have a limited "view" of the configuration
meta-data pertaining to the area of concern, like the cache (useful for
iteration/inspection purposes) rather than just a single, large object with
the entire system configuration (an implementation detail that need not be
exposed).  Also, I'd be careful in only exposing this from the
ClusterConfigurationService, since what does that have to do with clients?

-j



On Thu, Mar 29, 2018 at 3:33 PM, Kirk Lund  wrote:

> We should probably consider moving ServerLauncher and LocatorLauncher from
> org.apache.geode.distributed to a different package (maybe
> org.apache.geode?).
>
> On Thu, Mar 29, 2018 at 10:32 AM, John Blum  wrote:
>
> > Yes, framework and tooling.
> >
> > I see no reason why the functionality in
> > o.a.g.distributed.DistributedSystem [1]
> > should be hidden or internal.  I would certainly remove the deprecated
> > methods by now.  A few other methods are questionable as to whether they
> > really belong on the 

Re: [PROPOSAL] Deprecating DistributedSystem

[Kirk Lund]

We should probably consider moving ServerLauncher and LocatorLauncher from
org.apache.geode.distributed to a different package (maybe
org.apache.geode?).

On Thu, Mar 29, 2018 at 10:32 AM, John Blum  wrote:

> Yes, framework and tooling.
>
> I see no reason why the functionality in
> o.a.g.distributed.DistributedSystem [1]
> should be hidden or internal.  I would certainly remove the deprecated
> methods by now.  A few other methods are questionable as to whether they
> really belong on the DistributedSystem interface, e.g.
> releaseThreadsSockets().
>
> However, many of these methods are very useful, e.g.
> getDistributedMember(),
> findDistriubtedMember(..), and especially getProperties().
>
> In general, I don't really get the need to have any internal/hidden classes
> in Geode and why most aspects of Geode should not be open and/or
> extensible, i.e. "*Open for Extension; Closed for
> Modification"... Open/Closed Principal [2]*).  Most, if not all, APIs in
> Geode should have an interface and a provider implementation that is
> pluggable.  I don't see why the DistributedSystem is any different.
>
> -j
>
>
> [1]
> http://geode.apache.org/releases/latest/javadoc/org/
> apache/geode/distributed/DistributedSystem.html
> [2] https://en.wikipedia.org/wiki/Open/closed_principle
>
>
> On Thu, Mar 29, 2018 at 10:16 AM, Galen O'Sullivan 
> wrote:
>
> > It looks like there are a few JIRA tasks open to deprecate methods on
> > DistributedSystem, and it doesn't really have much functionality that
> would
> > be useful to a user. I propose that we deprecate DistributedSystem
> itself,
> > and keep the system management functionality internal. Is there any
> reason
> > why we shouldn't do this?
> >
> > Thanks,
> > Galen
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>

Re: [PROPOSAL] Deprecating DistributedSystem

[John Blum]

@Patrick - have a look at...
http://gemfire-93-javadocs.docs.pivotal.io/org/apache/geode/cache/execute/FunctionService.html#onMember-org.apache.geode.distributed.DistributedMember-



On Thu, Mar 29, 2018 at 2:23 PM, Patrick Rhomberg 
wrote:

> +1 to deprecation.
>
> @John, The context in which the findMember methods are useful is (as far as
> I can tell) limited to commands being run on a locator. These methods will
> remain accessible via the new public API in the (currently @Experimental)
> GfshCommand abstract class.
>
> Likewise, the configuration properties will be accessible via the (also
> currently @Experimental) ClusterConfigurationService interface, accessible
> via GfshCommand::getConfigurationService.
>
> On Thu, Mar 29, 2018 at 11:27 AM, Bruce Schuchardt  >
> wrote:
>
> > Yes, deprecate it.  I think the few useful methods that John pointed to
> > could be migrated to one of the other interfaces.  Everything else
> > primarily uses the DistributionManager for membership and messaging.
> >
> >
> > On 3/29/18 10:37 AM, Jacob Barrett wrote:
> >
> >> Yes please!! On the C++ client we have completely stripped it of its
> >> utility as part of removing global. It is all but and internal class
> >> holding the SystemProperties bag and some other things that Cache can
> >> really own.
> >>
> >> -Jake
> >>
> >>
> >> On Mar 29, 2018, at 10:16 AM, Galen O'Sullivan 
> >>> wrote:
> >>>
> >>> It looks like there are a few JIRA tasks open to deprecate methods on
> >>> DistributedSystem, and it doesn't really have much functionality that
> >>> would
> >>> be useful to a user. I propose that we deprecate DistributedSystem
> >>> itself,
> >>> and keep the system management functionality internal. Is there any
> >>> reason
> >>> why we shouldn't do this?
> >>>
> >>> Thanks,
> >>> Galen
> >>>
> >>
> >
>



-- 
-John
john.blum10101 (skype)

Re: [PROPOSAL] Deprecating DistributedSystem

[Patrick Rhomberg]

+1 to deprecation.

@John, The context in which the findMember methods are useful is (as far as
I can tell) limited to commands being run on a locator. These methods will
remain accessible via the new public API in the (currently @Experimental)
GfshCommand abstract class.

Likewise, the configuration properties will be accessible via the (also
currently @Experimental) ClusterConfigurationService interface, accessible
via GfshCommand::getConfigurationService.

On Thu, Mar 29, 2018 at 11:27 AM, Bruce Schuchardt 
wrote:

> Yes, deprecate it.  I think the few useful methods that John pointed to
> could be migrated to one of the other interfaces.  Everything else
> primarily uses the DistributionManager for membership and messaging.
>
>
> On 3/29/18 10:37 AM, Jacob Barrett wrote:
>
>> Yes please!! On the C++ client we have completely stripped it of its
>> utility as part of removing global. It is all but and internal class
>> holding the SystemProperties bag and some other things that Cache can
>> really own.
>>
>> -Jake
>>
>>
>> On Mar 29, 2018, at 10:16 AM, Galen O'Sullivan 
>>> wrote:
>>>
>>> It looks like there are a few JIRA tasks open to deprecate methods on
>>> DistributedSystem, and it doesn't really have much functionality that
>>> would
>>> be useful to a user. I propose that we deprecate DistributedSystem
>>> itself,
>>> and keep the system management functionality internal. Is there any
>>> reason
>>> why we shouldn't do this?
>>>
>>> Thanks,
>>> Galen
>>>
>>
>

Re: [PROPOSAL] Deprecating DistributedSystem

[Jacob Barrett]

Yes please!! On the C++ client we have completely stripped it of its utility as 
part of removing global. It is all but and internal class holding the 
SystemProperties bag and some other things that Cache can really own. 

-Jake


> On Mar 29, 2018, at 10:16 AM, Galen O'Sullivan  wrote:
> 
> It looks like there are a few JIRA tasks open to deprecate methods on
> DistributedSystem, and it doesn't really have much functionality that would
> be useful to a user. I propose that we deprecate DistributedSystem itself,
> and keep the system management functionality internal. Is there any reason
> why we shouldn't do this?
> 
> Thanks,
> Galen

Re: [PROPOSAL] Deprecating DistributedSystem

[John Blum]

Yes, framework and tooling.

I see no reason why the functionality in
o.a.g.distributed.DistributedSystem [1]
should be hidden or internal.  I would certainly remove the deprecated
methods by now.  A few other methods are questionable as to whether they
really belong on the DistributedSystem interface, e.g.
releaseThreadsSockets().

However, many of these methods are very useful, e.g. getDistributedMember(),
findDistriubtedMember(..), and especially getProperties().

In general, I don't really get the need to have any internal/hidden classes
in Geode and why most aspects of Geode should not be open and/or
extensible, i.e. "*Open for Extension; Closed for
Modification"... Open/Closed Principal [2]*).  Most, if not all, APIs in
Geode should have an interface and a provider implementation that is
pluggable.  I don't see why the DistributedSystem is any different.

-j


[1]
http://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/DistributedSystem.html
[2] https://en.wikipedia.org/wiki/Open/closed_principle


On Thu, Mar 29, 2018 at 10:16 AM, Galen O'Sullivan 
wrote:

> It looks like there are a few JIRA tasks open to deprecate methods on
> DistributedSystem, and it doesn't really have much functionality that would
> be useful to a user. I propose that we deprecate DistributedSystem itself,
> and keep the system management functionality internal. Is there any reason
> why we shouldn't do this?
>
> Thanks,
> Galen
>



-- 
-John
john.blum10101 (skype)