geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darrel Schneider (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (GEODE-72) Remove deprecated APIs from Geode
Date Tue, 25 Aug 2015 22:47:46 GMT

     [ https://issues.apache.org/jira/browse/GEODE-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Darrel Schneider updated GEODE-72:
----------------------------------
    Description: 
The Geode APIs are riddled with old, deprecated interfaces, methods and settings inherited
from GemFire.  Unless there is a good reason to keep them shouldn't we remove them all before
going out of incubation?

Sub-tasks have been added for most items. Here are the remaining items not yet added:

APIs deprecated in GemFire 5.1:
* DLS.lockInterruptibly(), suspendLockingInterruptibly()
 
APIs deprecated in an undocumented version prior to 5.7:
* Use of hostname:port to specify a locator in gemfire.properties
* AdminDistributedSystemFactory.bindToAddress()
 
APIs deprecated in GemFire 5.7:
* AdminDistributedSystemJmxImpl.manageCacheServer(), manageCacheServers()
 
APIs deprecated after GemFire 5.7 and before 8.0
* The com.gemstone.gemfire.admin and admin.jmx packages.  Some of the implementation is in
com.gemstone.gemfire.internal.remote.
* EvictionAlgorithm.LIFO_ENTRY, LIFO_MEMORY: these were deprecated but we never deprecated
EvictionAttributes.createLIFOEntryAttributes
nor EvictionAttributes.createLIFOMemoryAttributes. These algorithms are used internally by
the product when a server create a queue to send subscription events to a client (see BridgeServerImpl.clientMessagesRegion).
I think the algorithms were deprecated because we didn't intend to expose this internal feature
as an external one. But they are exposed externally via EvictionAttributes so it is not clear
that we can just delete them.
The other consideration is that we do not have xsd support nor gfsh support for LIFO.
* Region.getCache(): we should consider un-deprecating this. Customers were supposed to instead
call Region.getRegionService but in lots of cases they would need to down cast that result
to "Cache". Only clients that are calling ClientCache.createAuthenticatedView end up with
Regions whose getCache throws UnsupportedOperationException. Our code call getCache from over
500 places.
* DistributedSystem.connect(), disconnect()
* Locator.startLocator(int, File), startLocator(int, File, InetAddress) etc.
* Locator.getLocators(), hasLocators()

APIs deprecated since GemFire 5.7 with no version information mentioned
* UniversalMembershipListenerAdapter
* DistributedRegionMXBean.getDiskTaskWaiting()
* MemberMXBean.getCurrentHeapSize(), getMaximumHeapSize(), getFreeHeapSize()
* RegionMXBean.getDiskReadsAverageLatency(), getDiskWritesAverageLatency(), getDiskTaskWaiting()
 LocatorLauncher.DEFAULT_LOCATOR_PORT,  DEFAULT_ENABLE_PEER_LOCATION, DEFAULT_ENABLE_SERVER_LOCATION,

DEFAULT_LOCATOR_PID_FILE
* LocatorLauncher.stopWithPort()
* ServerLauncher.DEFAULT_SERVER_PORT, DEFAULT_SERVER_PID_FILE

Things that should be deprecated but are not:
* MembershipAttributes and “required roles”.
* DynamicRegions: if GEODE-215 is implemented then we could deprecate DynamicRegions and have
an alternative to change to. We have some support in the gfsh/management layer for creating
regions remotely which might be good enough to deprecate DynamicRegions. The question is should
we remove com.gemstone.gemfire.cache.DynamicRegionFactory even though it has not been deprecated.

APIs deprecated in 8.0.  It would probably be a nice gesture to Pivotal to keep these for
a while to allow people to migrate from their GemFire product to Geode.
* PutAllOperationContext.setMap()
* FixedPartitionResolver.getPartitionName(EntryOperation, Set<String>)
* ssl-enabled, ssl-protocols, ssl-ciphers, ssl-require-authentication, jmx-manager-ssl distribution
properties
* RegionMXBean.getAvgBucketSize()
* com.gemstone.gemfire.LicenseException

The Admin API and packages are also marked as deprecated but there seem to be some gfsh dependencies
on this API, so I'm not sure if it can be removed.

  was:
The Geode APIs are riddled with old, deprecated interfaces, methods and settings inherited
from GemFire.  Unless there is a good reason to keep them shouldn't we remove them all before
going out of incubation?

Sub-tasks have been added for most items. Here are the remaining items not yet added:

APIs deprecated in GemFire 5.0:
* AbstractRegion.setIgnoreJTA() (phase 2)
  
APIs deprecated in GemFire 5.1:
* DLS.lockInterruptibly(), suspendLockingInterruptibly()
 
APIs deprecated in an undocumented version prior to 5.7:
* Use of hostname:port to specify a locator in gemfire.properties
* AdminDistributedSystemFactory.bindToAddress()
* MessageFactory (phase 2)
 
APIs deprecated in GemFire 5.7:
* BridgePoolImpl (phase 2)
* The internal ForceDisconnectOperation (phase 2)
* AdminDistributedSystemJmxImpl.manageCacheServer(), manageCacheServers() (phase 2)
 
APIs deprecated after GemFire 5.7 and before 8.0
* The com.gemstone.gemfire.admin and admin.jmx packages.  Some of the implementation is in
com.gemstone.gemfire.internal.remote.
* EvictionAlgorithm.LIFO_ENTRY, LIFO_MEMORY: these were deprecated but we never deprecated
EvictionAttributes.createLIFOEntryAttributes
nor EvictionAttributes.createLIFOMemoryAttributes. These algorithms are used internally by
the product when a server create a queue to send subscription events to a client (see BridgeServerImpl.clientMessagesRegion).
I think the algorithms were deprecated because we didn't intend to expose this internal feature
as an external one. But they are exposed externally via EvictionAttributes so it is not clear
that we can just delete them.
The other consideration is that we do not have xsd support nor gfsh support for LIFO.
* Region.getCache(): we should consider un-deprecating this. Customers were supposed to instead
call Region.getRegionService but in lots of cases they would need to down cast that result
to "Cache". Only clients that are calling ClientCache.createAuthenticatedView end up with
Regions whose getCache throws UnsupportedOperationException. Our code call getCache from over
500 places.
* DistributedSystem.connect(), disconnect()
* Locator.startLocator(int, File), startLocator(int, File, InetAddress) etc.
* Locator.getLocators(), hasLocators()
* LocalRegion.notifyToRoll() (phase 2)

APIs deprecated since GemFire 5.7 with no version information mentioned
* UniversalMembershipListenerAdapter
* DistributedRegionMXBean.getDiskTaskWaiting()
* MemberMXBean.getCurrentHeapSize(), getMaximumHeapSize(), getFreeHeapSize()
* RegionMXBean.getDiskReadsAverageLatency(), getDiskWritesAverageLatency(), getDiskTaskWaiting()
 LocatorLauncher.DEFAULT_LOCATOR_PORT,  DEFAULT_ENABLE_PEER_LOCATION, DEFAULT_ENABLE_SERVER_LOCATION,

DEFAULT_LOCATOR_PID_FILE
* LocatorLauncher.stopWithPort()
* ServerLauncher.DEFAULT_SERVER_PORT, DEFAULT_SERVER_PID_FILE

Things that should be deprecated but are not:
* MembershipAttributes and “required roles”.
* DynamicRegions: if GEODE-215 is implemented then we could deprecate DynamicRegions and have
an alternative to change to. We have some support in the gfsh/management layer for creating
regions remotely which might be good enough to deprecate DynamicRegions. The question is should
we remove com.gemstone.gemfire.cache.DynamicRegionFactory even though it has not been deprecated.

APIs deprecated in 8.0.  It would probably be a nice gesture to Pivotal to keep these for
a while to allow people to migrate from their GemFire product to Geode.
* PutAllOperationContext.setMap()
* FixedPartitionResolver.getPartitionName(EntryOperation, Set<String>)
* ssl-enabled, ssl-protocols, ssl-ciphers, ssl-require-authentication, jmx-manager-ssl distribution
properties
* LocalProcessController: this class should be deleted. It's internal and does not need to
be deprecated.
* RegionMXBean.getAvgBucketSize()
* com.gemstone.gemfire.LicenseException

The Admin API and packages are also marked as deprecated but there seem to be some gfsh dependencies
on this API, so I'm not sure if it can be removed.


> Remove deprecated APIs from Geode
> ---------------------------------
>
>                 Key: GEODE-72
>                 URL: https://issues.apache.org/jira/browse/GEODE-72
>             Project: Geode
>          Issue Type: Improvement
>    Affects Versions: 1.0.0-incubating
>            Reporter: Bruce Schuchardt
>              Labels: cleanup
>
> The Geode APIs are riddled with old, deprecated interfaces, methods and settings inherited
from GemFire.  Unless there is a good reason to keep them shouldn't we remove them all before
going out of incubation?
> Sub-tasks have been added for most items. Here are the remaining items not yet added:
> APIs deprecated in GemFire 5.1:
> * DLS.lockInterruptibly(), suspendLockingInterruptibly()
>  
> APIs deprecated in an undocumented version prior to 5.7:
> * Use of hostname:port to specify a locator in gemfire.properties
> * AdminDistributedSystemFactory.bindToAddress()
>  
> APIs deprecated in GemFire 5.7:
> * AdminDistributedSystemJmxImpl.manageCacheServer(), manageCacheServers()
>  
> APIs deprecated after GemFire 5.7 and before 8.0
> * The com.gemstone.gemfire.admin and admin.jmx packages.  Some of the implementation
is in com.gemstone.gemfire.internal.remote.
> * EvictionAlgorithm.LIFO_ENTRY, LIFO_MEMORY: these were deprecated but we never deprecated
EvictionAttributes.createLIFOEntryAttributes
> nor EvictionAttributes.createLIFOMemoryAttributes. These algorithms are used internally
by the product when a server create a queue to send subscription events to a client (see BridgeServerImpl.clientMessagesRegion).
I think the algorithms were deprecated because we didn't intend to expose this internal feature
as an external one. But they are exposed externally via EvictionAttributes so it is not clear
that we can just delete them.
> The other consideration is that we do not have xsd support nor gfsh support for LIFO.
> * Region.getCache(): we should consider un-deprecating this. Customers were supposed
to instead call Region.getRegionService but in lots of cases they would need to down cast
that result to "Cache". Only clients that are calling ClientCache.createAuthenticatedView
end up with Regions whose getCache throws UnsupportedOperationException. Our code call getCache
from over 500 places.
> * DistributedSystem.connect(), disconnect()
> * Locator.startLocator(int, File), startLocator(int, File, InetAddress) etc.
> * Locator.getLocators(), hasLocators()
> APIs deprecated since GemFire 5.7 with no version information mentioned
> * UniversalMembershipListenerAdapter
> * DistributedRegionMXBean.getDiskTaskWaiting()
> * MemberMXBean.getCurrentHeapSize(), getMaximumHeapSize(), getFreeHeapSize()
> * RegionMXBean.getDiskReadsAverageLatency(), getDiskWritesAverageLatency(), getDiskTaskWaiting()
>  LocatorLauncher.DEFAULT_LOCATOR_PORT,  DEFAULT_ENABLE_PEER_LOCATION, DEFAULT_ENABLE_SERVER_LOCATION,

> DEFAULT_LOCATOR_PID_FILE
> * LocatorLauncher.stopWithPort()
> * ServerLauncher.DEFAULT_SERVER_PORT, DEFAULT_SERVER_PID_FILE
> Things that should be deprecated but are not:
> * MembershipAttributes and “required roles”.
> * DynamicRegions: if GEODE-215 is implemented then we could deprecate DynamicRegions
and have an alternative to change to. We have some support in the gfsh/management layer for
creating regions remotely which might be good enough to deprecate DynamicRegions. The question
is should we remove com.gemstone.gemfire.cache.DynamicRegionFactory even though it has not
been deprecated.
> APIs deprecated in 8.0.  It would probably be a nice gesture to Pivotal to keep these
for a while to allow people to migrate from their GemFire product to Geode.
> * PutAllOperationContext.setMap()
> * FixedPartitionResolver.getPartitionName(EntryOperation, Set<String>)
> * ssl-enabled, ssl-protocols, ssl-ciphers, ssl-require-authentication, jmx-manager-ssl
distribution properties
> * RegionMXBean.getAvgBucketSize()
> * com.gemstone.gemfire.LicenseException
> The Admin API and packages are also marked as deprecated but there seem to be some gfsh
dependencies on this API, so I'm not sure if it can be removed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message