geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Markito Oliveira (JIRA)" <>
Subject [jira] [Updated] (GEODE-72) Remove deprecated APIs from Geode
Date Wed, 11 May 2016 01:37:12 GMT


William Markito Oliveira updated GEODE-72:
    Fix Version/s: 2.0.0-incubating

> Remove deprecated APIs from Geode
> ---------------------------------
>                 Key: GEODE-72
>                 URL:
>             Project: Geode
>          Issue Type: Improvement
>    Affects Versions: 1.0.0-incubating
>            Reporter: Bruce Schuchardt
>              Labels: cleanup, docs
>             Fix For: 2.0.0-incubating
> 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
> APIs deprecated after GemFire 5.7 and before 8.0
> * EvictionAlgorithm.LIFO_ENTRY, LIFO_MEMORY: these were deprecated but we never deprecated
> 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.
> * Locator.startLocator(int, File), startLocator(int, File, InetAddress) etc.
> * Locator.getLocators(), hasLocators()
> APIs deprecated since GemFire 5.7 with no version information mentioned
> * DistributedRegionMXBean.getDiskTaskWaiting()
> * MemberMXBean.getCurrentHeapSize(), getMaximumHeapSize(), getFreeHeapSize()
> * RegionMXBean.getDiskReadsAverageLatency(), getDiskWritesAverageLatency(), getDiskTaskWaiting()
> 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.
> Deprecated in 7.0 and not previously in this list:
> * UniversalMembershipListenerAdapter
> 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()
> 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.
> Also consider removing com.gemstone.gemfire.cache.partition.PartitionListener and com.gemstone.gemfire.cache.partition.PartitionManager.
> They have not been deprecated but were never fully supported. Their javadocs say:
>   Note : Please contact before using these APIs

This message was sent by Atlassian JIRA

View raw message