geode-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dbar...@apache.org
Subject [11/25] geode-native git commit: Simplify doc directory structure - remove redundant top layer
Date Tue, 14 Feb 2017 20:11:12 GMT
http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/cache-init-file/example-cache-file.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/cache-init-file/example-cache-file.html.md.erb b/geode-docs/docs/geode-native-docs/cache-init-file/example-cache-file.html.md.erb
deleted file mode 100644
index 2ad56b0..0000000
--- a/geode-docs/docs/geode-native-docs/cache-init-file/example-cache-file.html.md.erb
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title:  Example cache.xml File
----
-
-An example `cache.xml` file shows cache and region initialization for a client, presenting a subset of the possible data configurations.
-
-For detailed information about cache and region configuration, including the default attribute settings, see [The Native Client Cache](../client-cache/chapter-overview.html#native-client-cache). Also see the online API documentation for `Cache` and `RegionAttributes`.
-
-For information a cache with server pool, see [Using Connection Pools](../connection-pools/connection-pools.html#using-connection-pools). The example below shows a `cache.xml` file that creates two regions.
-
--   Region `region1` is defined with a full set of region attributes and application plug-ins. The region's entries have `RegionTimeToLive` and `RegionIdleTimeout` expiration attributes set ([Expiration Attributes](../client-cache/expiration-attributes.html#expiration-attributes)).
--   Region `region2` uses mostly default values.
-
-``` pre
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE cache PUBLIC
-    "-//Example Systems, Inc.//Example Declarative Caching 8.0//EN"
-    "http://www.example.com/dtd/gfcpp-cache8000.dtd">
-<!-- Sample cache.xml file -->
-<!-- Example Declarative Cache Initialization with cache.xml -->
-<cache>
-    <pool name="examplePool" subscription-enabled="true">
-        <server host="localhost" port="24680" />
-    </pool>
-    <region name="root1" refid="CACHING_PROXY">
-        <region-attributes pool-name="examplePool"
-            initial-capacity="25"
-            load-factor="0.32"
-            concurrency-level="10"
-            lru-entries-limit="35">
-            <region-idle-time>
-                <expiration-attributes timeout="20" action="destroy"/>
-            </region-idle-time>
-            <entry-idle-time>
-                <expiration-attributes timeout="10" action="invalidate"/>
-            </entry-idle-time>
-            <region-time-to-live>
-                <expiration-attributes timeout="5" action="local-destroy"/>
-            </region-time-to-live>
-            <entry-time-to-live>
-                <expiration-attributes timeout="10" action="local-invalidate"/>
-            </entry-time-to-live>
-        </region-attributes>
-    </region>
-</cache>
-```
-
-For details about the individual region attributes, see [Region Attributes](../client-cache/region-attributes.html#region-attributes).

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/cache-init-file/file-basics.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/cache-init-file/file-basics.html.md.erb b/geode-docs/docs/geode-native-docs/cache-init-file/file-basics.html.md.erb
deleted file mode 100644
index ca6fcca..0000000
--- a/geode-docs/docs/geode-native-docs/cache-init-file/file-basics.html.md.erb
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title:  Cache Initialization File Basics
----
-
-The contents of the cache initialization file are used to populate or update a cache.
-
-This occurs when a cache server starts up, when a client application explicitly creates its cache, or when a client explicitly loads a new structure into an existing cache.
-
-The initialization file can have any name, but is generally referred to as `cache.xml`. Both client applications and cache servers can use an optional `cache.xml` file to ease the initialization process.
-
-## <a id="file-basics__section_E54BF7911C224016B822768B537FA464" class="no-quick-link"></a>File Contents
-
-The contents of a declarative XML file correspond to APIs declared in the `Cache.hpp` and `Region.hpp` header files. The cache initialization file allows you to accomplish declaratively many of the cache management activities that you can program through the API.
-
--   The contents of the cache initialization file must conform to the XML definition in `productDir/dtd/gfcpp-cache8000.dtd` (see [Native Client Cache XML DTD](cache-dtd.html#cache-dtd)).
--   The name of the declarative XML file is specified when establishing a connection to the distributed system. You can define it by setting the `cache-xml-file` configuration attribute in the `gfcpp.properties` file for the native client. For details about the `gfcpp.properties` file, see [Setting System and Cache Properties](../setting-properties/chapter-overview.html#system_and_cache_properties).
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/accessing-entries.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/accessing-entries.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/accessing-entries.html.md.erb
deleted file mode 100644
index 34090fc..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/accessing-entries.html.md.erb
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title:  Accessing Entries
----
-
-<a id="accessing-entries__section_310C0BE952BC489C9E97811DAE8736E4"></a>
-Use the API to retrieve the entry key, entry value, and the `RegionEntry` object itself. A variety of functions provide information for individual entries and for the set of all entries resident in the region. The API documentation at [http://gemfire-apis.docs.pivotal.io](http://gemfire-apis.docs.pivotal.io) lists all available access functions.
-
-A region's entry keys and `RegionEntry` objects are directly available from the local cache. Applications can directly access the local cache's stored entry value through the `RegionEntry::getValue` function. The `getValue` function either returns the value if a valid value is present in the local cache, or `NULL` if the value is not valid locally. This function does no data loading, nor does it look elsewhere in the distributed system for a valid value.
-
-**Note:** Direct access through `RegionEntry::getValue` does not reset an entry's timestamp for LRU expiration. See [Specifying Expiration Attributes](expiration-attributes.html) for more information about LRU expiration.
-
-In comparison, the standard `Region::get` functions consider all caches and all applicable loaders in the distributed system in an attempt to return a valid entry value to the calling application. The primary attribute setting affecting entry retrieval is `CacheLoader`. See [Specifying Application Plug-In Attributes](application-plugins.html).
-
-The standard `Region::get` functions may implement a number of operations in order to retrieve a valid entry value. The operations used depend on the region's attribute settings and on the state of the entry itself. By default, the client retrieves entry values through calls to the `get` function. The client can override this behavior for any region by defining a cache loader for the region.
-
-The following sections discuss the `get` function and special considerations for entry retrieval.
-
-## <a id="accessing-entries__section_AD6AFD842C144C128FA1C7F0B9283372" class="no-quick-link"></a>Entry Retrieval
-
-You retrieve entry values with the `Region::get` function.
-
-When an entry value is requested from a region, it is either retrieved from the cache server or fetched by the region's locally-defined cache loader in this sequence:
-
-1.  local cache search
-2.  server cache
-3.  local load (For distributed regions, the local load is fetched before remote cache values)
-
-## <a id="accessing-entries__section_82B624FE364F4034AF010D20A8D0DF68" class="no-quick-link"></a>How the get Operation Affects the Local Entry Value
-
-If a `get` operation retrieves an entry value from outside the local cache through a local load, it automatically `put`s the value into the cache for future reference.
-
-Note that these load operations do not invoke a cache writer. Because the loader and writer operate against the same data source, you do not need to perform a cache write for entries that were just fetched from that data source. For descriptions of these processes, see the [Overview of Application Plug-Ins](application-plugins.html#application-plugins__section_8FEB62EEC7A042E0A85E0FEDC9F71597).
-
-**Note:** Access through a `get` operation resets an entry's timestamp for LRU expiration.
-
-## <a id="accessing-entries__section_F636614605C84513B2B7F4A674FD6E38" class="no-quick-link"></a>Getting Multiple Entries Using getAll
-
-You can use the `getAll` Region API to get all values for an array of keys from the local cache or cache server. Subsection [Bulk Put Operations Using putAll](../cpp-caching-api/add-entry-to-cache.html#concept_26D4E6C6BC6F4AB8884E33119999656D__section_748916759F0246619CD27E7456DCA365) has more information.

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/adding-entries-to-cache.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/adding-entries-to-cache.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/adding-entries-to-cache.html.md.erb
deleted file mode 100644
index 6b55120..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/adding-entries-to-cache.html.md.erb
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title:  Adding Entries to the Cache
----
-
-<a id="adding-entries-to-cache__section_57CE90DC5C694CB79F05C943DE6F5E4B"></a>
-A region is populated with cached entries in several ways:
-
--   Explicitly, when an application executes a `create` or a `put` operation for a single entry or for multiple entries that do not already exist in the cache.
--   Implicitly, when a client does a get on a single entry or on multiple entries that do not already exist in the cache. In this case, the entry is retrieved from a remote cache or through a cache loader. 
-Read about cache loaders at [Overview of Application Plug-Ins](application-plugins.html#application-plugins__section_8FEB62EEC7A042E0A85E0FEDC9F71597).
-A client can also use `getAll` to populate a region with all values for an array of keys. See [Accessing Entries](accessing-entries.html).
--   Automatically, when entries are created in remote caches.
-
-If any cache writer is available in the distributed region, it is called before the entry is created and it can abort the creation process.
-
-**Note:**
-For more information on how to create entries, see [Pivotal GemFire Native Client C++ API](../cpp-caching-api/cpp-caching-api.html), [Pivotal GemFire Native Client .NET API](../dotnet-caching-api/dotnet-caching-api.html), and the native client API reference at [http://gemfire-apis.docs.pivotal.io](http://gemfire-apis.docs.pivotal.io).
-
-## <a id="adding-entries-to-cache__section_873FFF2CAC804B8E9676AB8098CF2434" class="no-quick-link"></a>Adding Entries to the Local Cache
-
-If just the local cache is to be populated, you can either `create` an entry using the `localCreate` Region API, or `put` an entry using `localPut`. See the C++ and .NET API documentation at [http://gemfire-apis.docs.pivotal.io](http://gemfire-apis.docs.pivotal.io) for details about `localCreate` and `localPut`.
-
-`DateTime` objects must be stored in the cache in UTC, so that times correspond between client and server. If you use a date with a different time zone, convert it when storing into and retrieving from the cache. This example converts a local time to UTC for a put operation:
-
-``` pre
-DateTime t1( 2009, 8, 13, 4, 11, 0, DateTimeKind.Local);
-region0.Put( 1, t1.ToUniversalTime() );
-```
-
-## <a id="adding-entries-to-cache__section_7CFEB263E2FE4775A3C9A29351A33911" class="no-quick-link"></a>Adding Multiple Entries Using PutAll
-
-If you need to add many cache entries to a region at one time, you can improve cache performance by using the `putAll` function to add them in a single distributed operation. Multiple key/value pairs are stored in a hashmap, then the hashmap contents are processed on the server as either new entries, updates, or invalidates for existing entries.
-
-Under [Adding an Entry to the Cache](../cpp-caching-api/add-entry-to-cache.html) see the subsection titled Bulk Put Operations Using putAll for more information about the `putAll` API. Additional details are available in the API documentation for `Region::putAll` (C++), or `Region.PutAll` (.NET) at [http://gemfire-apis.docs.pivotal.io](http://gemfire-apis.docs.pivotal.io).

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/application-plugins.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/application-plugins.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/application-plugins.html.md.erb
deleted file mode 100644
index 8d9204c..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/application-plugins.html.md.erb
+++ /dev/null
@@ -1,262 +0,0 @@
----
-title: Application Plug-ins
----
-<a id="application-plugins__section_8FEB62EEC7A042E0A85E0FEDC9F71597" class="no-quick-link"></a>
-
-The API provides the framework for application plug-ins with callback functions for the appropriate events. Your classes and functions can customize these for your application's needs. When creating a region, specify these as part of the region's attributes settings. For regions already in the cache, you can specify new `CacheLoader`, `CacheWriter`, and `CacheListener` using the region's `AttributesMutator`. The `PartitionResolver` is not mutable.
-
--   `CacheLoader`: A data loader called when an entry get operation fails to find a value for a given key. A cache loader is generally used to retrieve data from an outside source such as a database, but it may perform any operation defined by the user. Loaders are invoked as part of the distributed loading activities for entry retrieval, described in [Entry Retrieval](accessing-entries.html#accessing-entries__section_AD6AFD842C144C128FA1C7F0B9283372).
--   `CacheWriter`: A synchronous event listener that receives callbacks before region events occur and has the ability to abort the operations. Writers are generally used to keep a back-end data source synchronized with the cache.
--   `CacheListener`: An asynchronous event listener for region events in the local cache.
--   `PartitionResolver`: Used for single-hop access to partitioned region entries on the server side. This resolver implementation must match that of the `PartitionResolver` on the server side.
-
-The following XML declaration specifies a cache loader for a region when the region is created.
-
-``` pre
-<region-attributes>
-    <cache-loader library-name="appl-lib"
-        library-function-name ="createCacheLoader">
-    </cache-loader>
-</region-attributes>
-```
-
-The rest of this section gives more detailed descriptions of these application plug-ins, followed by special considerations for plug-ins in distributed regions and some guidelines for writing callbacks.
-
-## <a id="application-plugins__section_FD3057C0416840BAB76850E115F48B5C" class="no-quick-link"></a>CacheLoader
-
-A cache loader is an application plug-in used to load data into the region. When an entry is requested that is unavailable in the region, a cache loader may be called upon to load it. Generally, you use a cache loader to retrieve the data from a database or another source outside the distributed system, but it may perform any operation defined by the user.
-
-The `CacheLoader` interface provides one function, `load`, for customizing region entry loading. A distributed region may have cache loaders defined in any or all caches where the region is defined. When loading an entry value, a locally defined cache loader is always used before a remote loader. In distributed regions, loaders are available for remote entry retrieval.
-
-## <a id="application-plugins__section_1754F575011742A59149FD280CEA0F16" class="no-quick-link"></a>CacheWriter
-
-A cache writer is an application plug-in that synchronously handles changes to a region's contents. It is generally used to keep back-end data sources synchronized with a cache region. A cache writer has callback functions to handle region destruction and entry creation, update, and destruction. These functions are all called before the modification has taken place and can abort the operation.
-
-You can also use cache writers to store data that you want to make persistent.
-
-## <a id="application-plugins__section_3F43B898CD254076B4DD777E9B4CC8F0" class="no-quick-link"></a>CacheListener
-
-A cache listener is an application plug-in that asynchronously handles changes to a region's contents. A cache listener has callback functions to handle region destruction and invalidation, along with entry creation, update, invalidation, and destruction. These functions are called asynchronously after the modification has taken place.
-
-This declarative XML example establishes a cache listener when a region is created:
-
-``` pre
-<region name="region11">
-    <region-attributes>
-        <cache-listener library-name="appl-lib"
-            library-function-name ="createCacheListener" />
-    </region-attributes>
-</region>
-```
-
-Unlike cache loaders and cache writers, cache listeners only receive events for entries to which the client has performed operations or registered interest.
-
-When the listener is attached to a region with caching disabled, the old value is always `NULL`.
-
-**Note:**
-Do not perform region operations inside the cache listener. Once you have configured a cache listener, the event supplies the new entry values to the application. Performing a get with a key from the `EntryEvent` can result in distributed deadlock. For more about this, see the API documentation for `EntryEvent` at [http://gemfire-apis.docs.pivotal.io](http://gemfire-apis.docs.pivotal.io).
-
-When a region disconnects from a cache listener, you can implement the `afterRegionDisconnected` callback event. This callback event is only be invoked when using the `pool` API and `subscription` is enabled on the pool. For example:
-
-``` pre
-class DisconnectCacheListener : public CacheListener
-{
-    void afterRegionDisconnected( const RegionPtr& region )
-    {
-        printf("After Region Disconnected event received");
-    }
-};
-```
-
-## <a id="application-plugins__section_348E00A84F274D4B9DBA9ECFEB2F012E" class="no-quick-link"></a>PartitionResolver
-
-This section pertains to data access in server regions that have custom partitioning. Custom partitioning uses a Java `PartitionResolver` to colocate like data in the same buckets. For the client, you can use a `PartitionResolver` that matches the server's implementation to access data in a single hop. With single-hop data access, the client pool maintains information on where a partitioned region's data is hosted. When accessing a single entry, the client directly contacts the server that hosts the key--in a single hop.
-
-**Note:**
-Single hop is used for the following operations: `put`, `get`, `destroy`, `putAll`, `getAll`, `removeAll` and `onRegion` function execution.
-
-**Implementing Single-Hop on a Partitioned Region**
-
-1.  Make sure the pool attribute, `pr-single-hop-enabled`, is set to `true` or not set. It is `true` by default.
-2.  If the server uses a custom `PartitionResolver` install an implementation of `PartitionResolver` in the client region that returns, entry for entry, the same value as the server's Java `PartitionResolver` implementation. The server uses the resolver to colocate like data within a partitioned region.
-
-    If the server does not use a custom resolver, the default resolvers in client and server match, so single hop will work there by default.
-
-Disable single hop behavior for a region by setting its pool attribute `pr-single-hop-enabled` to `false`.
-
-See [&lt;client-cache&gt; Element Reference](geodeman/reference/topics/client-cache.html) for information on setting `pr-single-hop-enabled`.
-
-See [Partitioned Regions](geodeman/developing/partitioned_regions/chapter_overview.html) for more information, including colocating like data within a partitioned region and how to get the best performance with PR single hop.
-
-**Implementing a PartitionResolver**
-
-See [Custom-Partitioning and Colocating Data](geodeman/developing/partitioned_regions/overview_custom_partitioning_and_data_colocation.html) for information on custom-partitioning the server partitioned regions.
-
-1.  Implement `PartitionResolver` in the same place that you did in the server--custom class, key, or cache callback argument.
-2.  Program the resolver's functions the same way you programmed them in the Java implementation. Your implementation must match the server's.
-
-    Example of programming the `PartitionResolver` in C++:
-
-    ``` pre
-    class TradeKeyResolver : public PartitionResolver
-    {
-    private:
-        string m_tradeID;
-        int m_month;
-        int m_year;
-    public:
-        TradeKeyResolver() { }
-        TradeKeyResolver(int month, int year) {
-            m_month = month;
-            m_year = year;
-        }
-
-        ~TradeKeyResolver() { }
-
-        static PartitionResolverPtr createTradeKeyResolver() {
-            PartitionResolverPtr tradeKeyResolver( new TradeKeyResolver());
-        return tradeKeyResolver;
-        }
-        const char* getName() {
-            return "TradeKey";
-        }
-        CacheableKeyPtr getRoutingObject(const EntryEvent& opDetails) {
-            return CacheableKey::create(m_month + m_year);
-        }
-    };
-    ```
-
-    Example of programming the `PartitionResolver` in C\#:
-
-    ``` pre
-    using System;
-    using System.Threading;
-    // Use the GemFire namespace
-    using GemStone.GemFire.Cache;
-    class TradeKeyResolver : IPartitionResolver
-    {
-        private int m_month = 0;
-        private int m_year = 0;
-
-        public static TradeKeyResolver CreateTradeKeyResolver()
-        {
-            return new TradeKeyResolver();
-        }
-
-        public virtual ICacheableKey GetRoutingObject(EntryEvent entry)
-        {
-            return new CacheableInt32(m_month + m_year);
-        }
-
-        public virtual String GetName()
-        {
-            return "TradeKeyResolver";
-        }
-    }
-    ```
-
-3.  Install the resolver in the region. Use one of these methods:
-
-    XML partition resolver declaration:
-
-    ``` pre
-    <region name="trades" refid="CACHING_PROXY">
-        <region-attributes>
-            <partition-resolver library-name="appl-lib" library-function-name=
-            "createTradeKeyResolver"/>
-        </region-attributes>
-    </region>
-    <pool free-connection-timeout="12345" idle-timeout="5555"
-            load-conditioning-interval="23456" max-connections="7"
-            min-connections="3" name="test_pool_1" ping-interval="12345"
-            read-timeout="23456" retry-attempts="3" server-group="ServerGroup1"
-            socket-buffer-size="32768" statistic-interval="10123"
-            subscription-ack-interval="567" subscription-enabled="true"
-            subscription-message-tracking-timeout="900123"
-            subscription-redundancy="0" thread-local-connections="5"
-            pr-single-hop-enabled="true" >
-        <locator host="localhost" port="34756"/>
-    </pool>
-    ```
-
-    Programmatic partition resolver installation:
-
-    ``` pre
-    void setPartitionResolver()
-    {
-        CachePtr cachePtr = CacheFactory::createCacheFactory()->create();
-        PartitionResolverPtr resolver( new TradeKeyResolver());
-        RegionFactoryPtr regionFactory =
-            cachePtr->createRegionFactory(PROXY)
-            ->setClientNotificationEnabled(true)
-            ->setPartitionResolver(resolver);
-        RegionPtr regionPtr = regionFactory->create( "Trades" );
-    }
-    ```
-
-Your implementation of `PartitionResolver` must match that of the server side.
-
-## <a id="application-plugins__section_4EC30A57C37E4DDF83990A264D2C0284" class="no-quick-link"></a>Using AttributesMutator to Modify a Plug-In
-
-A cache listener, cache loader or cache writer can be added to or removed from a region after the region is created by retrieving and running the `Region` object's `AttributesMutator`. Mutable attributes define operations that are run from the client itself.
-
-This example shows how to use `AttributesMutator` to dynamically add a cache listener to an existing region.
-
-``` pre
-void setListener(RegionPtr& region)
-{
-    CacheListenerPtr regionListener = new TestCacheListener();
-    AttributesMutatorPtr regionAttributesMutator =
-        region->getAttributesMutator();
-
-    // Change cache listener for region.
-    regionAttributesMutator->setCacheListener(regionListener);
-}
-```
-
-The plug-ins can also be implemented using a dynamically linked library. The class is not available to the application code in this case, so a `factory` method is required by the `set` function along with the name of the library.
-
-This example shows how to use `AttributesMutator` along with the `setCacheListener` function to obtain a new cache listener object using the `factory` function provided by the library. Next, the listener is set for the region.
-
-``` pre
-void setListenerUsingFactory(RegionPtr& region)
-{
-    AttributesMutatorPtr regionAttributesMutator =
-    region->getAttributesMutator();
-
-    // Change cache listener for region.
-    regionAttributesMutator->setCacheListener("Library", "createTestCacheListener");
-}
-```
-
-To use `AttributesMutator` to remove a plug-in from a region, set the plug-in's value to `NULLPTR`, as shown in the following example.
-
-``` pre
-void removeListener(RegionPtr& region)
-{
-    CacheListenerPtr nullListener = NULLPTR;
-    AttributesMutatorPtr regionAttributesMutator =
-        region->getAttributesMutator();
-
-    // Change cache listener for region to NULLPTR
-    regionAttributesMutator->setCacheListener(nullListener);
-}
-```
-
-## <a id="application-plugins__section_428DCC57B6344603AA19DCAFCE483A10" class="no-quick-link"></a>Considerations for Implementing Callbacks
-
-Keep your callback implementations lightweight and prevent situations that might cause them to hang. For example, do not perform distribution operations or disconnects inside events.
-
-Your code should handle any exceptions that it generates. If not, Geode handles them as well as possible. Because C++ has no standard for exceptions, in many cases Geode can only print an `unknown error` message.
-
-## <a id="application-plugins__section_E81DB00AE0784BA2819DB3683C257647" class="no-quick-link"></a>Specifying Application Plug-In Attributes
-
-The plug-in attributes allow you to customize client region behavior for loading, updating, deleting, and overflowing region data and for accessing data in server partitioned regions. All client plug-ins are available through the C++ and .NET API.
-
-Application plug-ins for cache regions in clients can be declared either programmatically or in the `cache.xml` file.
-
-
-<a id="application-plugins__fig_630074710E134805A96B50AA5373866F"></a>
-<span class="figtitleprefix">Figure: </span>Where Application Plug-Ins Run
-
-<img src="../common/images/client-cache-plugins-run.gif" alt="Where Application Plug-Ins Run" id="application-plugins__image_23F82DD7DCD543239F3A75F112282C46" class="image" />

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/cache-management.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/cache-management.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/cache-management.html.md.erb
deleted file mode 100644
index cbd170d..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/cache-management.html.md.erb
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title:  Cache Management
----
-
-This section covers cache management.
-
-<a id="using-thread-safety__section_165DAD3CE6CA44D9A883FC91D4F09343"></a>
-
--   **[Client-to-Server Connection Process](client-to-server-connection.html)**
-
-    It is important to understand the sequence of events that occur when the native client connects with a Geode cache server.
-
--   **[Controlling Cache Size](controlling-cache-size.html)**
-
-    You can control cache size through region size limits, cache size limits, or a combination of the two.
-
--   **[Managing the Lifetime of a Cached Object](managing-lifetime-cached-object.html)**
-
-    All cacheable objects derive from `SharedBase` , which provides reference counting. Cacheable objects are referenced using `SharedPtr` types.
-
--   **[Using Thread Safety in Cache Management](using-thread-safety.html)**
-
-    When you perform structural changes on your cache, such as creating or closing a `Cache`, `Pool`, or `Region`, synchronize your operations or do them in a single thread.
-
--   **[Troubleshooting](troubleshooting.html)**
-
-    This section provides troubleshooting information for the native client.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/cache-ownership.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/cache-ownership.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/cache-ownership.html.md.erb
deleted file mode 100644
index 37f010c..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/cache-ownership.html.md.erb
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title:  Local, Remote, and Distributed Caches
----
-
-The *distributed system* defines how native client and cache server processes find each other.
-
-The distributed system keeps track of its membership list and makes its members aware of the identities of the other members in the distributed system.
-
-A cache for a native client is referred to as its *local cache*. All other caches in the distributed system are considered *remote caches* to the application. Every cache server and application process has its own cache. The term *distributed cache* is used to describe the union of all caches in a Geode distributed system.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/caches.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/caches.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/caches.html.md.erb
deleted file mode 100644
index 5d658c7..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/caches.html.md.erb
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title:  Caches
----
-
-The cache is the entry point to native client data caching in Geode. Through the cache, native clients gain access to the Geode caching framework for data loading, distribution, and maintenance.
-
--   **[About the Native Client Cache](overview-client-cache.html)**
-
-    The cache consists of data regions, each of which can contain any number of entries. Region entries hold the cached data. Every entry has a key that uniquely identifies it within the region and a value where the data object is stored.
-
--   **[Cache APIs](caching-apis.html)**
-
-    The native client has two cache APIs, `RegionService` and `Cache`.
-
--   **[Local, Remote, and Distributed Caches](cache-ownership.html)**
-
-    The *distributed system* defines how native client and cache server processes find each other.
-
--   **[Creating and Accessing a Cache](create-access-cache.html)**
-
-    When you create a native client cache, you are creating a native client cache instance. You must provide some basic configuration information such as a connection name and cache initialization parameters for the native client's cache instance.
-
--   **[Closing the Cache](closing-cache.html)**
-
-    Use the `Cache::close` function to release system resources when you finish using the cache.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/caching-apis.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/caching-apis.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/caching-apis.html.md.erb
deleted file mode 100644
index 08436c0..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/caching-apis.html.md.erb
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title:  Cache APIs
----
-
-The native client has two cache APIs, `RegionService` and `Cache`.
-
-## <a id="caching-apis__section_8F81996678B64BBE94EF352527F7F006" class="no-quick-link"></a>RegionService API
-
-`RegionService` provides:
-
--   Access to existing cache regions.
--   Access to the standard query service for the cache, which sends queries to the servers. See [Remote Querying](../remote-querying/remote-querying.html) and [Continuous Querying](../continuous-querying/continuous-querying.html).
-
-`RegionService` is inherited by `Cache`.
-
-You do not use instances of `RegionService` except for secure client applications with many users. See [Creating Multiple Secure User Connections with RegionService](../security/createsecureconnregionservice.html).
-
-## <a id="caching-apis__section_403383B9B5044A939A89A5BBB4915452" class="no-quick-link"></a>Cache API
-
-Use the `Cache` to manage your client caches. You have one `Cache` per client.
-
-The `Cache` inherits `RegionService` and adds management of these client caching features:
-
--   Region creation.
--   Subscription keepalive management for durable clients.
--   Access to the underlying distributed system.
--   `RegionService` creation for secure access by multiple users.
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/caching-enabled.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/caching-enabled.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/caching-enabled.html.md.erb
deleted file mode 100644
index 7f4e6cf..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/caching-enabled.html.md.erb
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title:  CachingEnabled
----
-
-This attribute determines whether data is cached in this region. For example, you might choose to configure the distributed system as a simple messaging service where clients run without a cache.
-
-**Note:**
-You can configure the most common of these options with the predefined region attributes. See [Region Shortcuts](region-shortcuts.html#region-shortcuts) and the Javadocs for `RegionShortcut`.
-
-If `CachingEnabled` is false (no caching), an `IllegalStateException` is thrown if any of these attributes are set:
-
--   [InitialCapacity](initial-capacity.html#initial-capacity)
--   `EntryTimeToLive` under [Specifying Expiration Attributes](expiration-attributes.html#expiration-attributes)
--   `EntryIdleTimeout` under [Specifying Expiration Attributes](expiration-attributes.html#expiration-attributes)
--   [LoadFactor](load-factor.html#load-factor)
--   [ConcurrencyLevel](concurrency-level.html#concurrency-level)
--   [LruEntriesLimit](lru-entries-limit.html#concept_75D723D60E044FF9AE97C939699AB10A)
--   [DiskPolicy](disk-policy.html#disk-policy)
-
-The following declaration enables caching for the region:
-
-``` pre
-<region-attributes caching-enabled="true"> 
-</region-attributes>
-```
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/chapter-overview.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/chapter-overview.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/chapter-overview.html.md.erb
deleted file mode 100644
index 9f0ea01..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/chapter-overview.html.md.erb
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title:  Configuring the Native Client Cache
----
-
-*Configuring the Native Client Cache* describes the native client cache functionality, initialization file, and APIs. It provides information about creating and working with caches, cache regions, and region entries.
-
-The native client cache provides a framework for native clients to store, manage, and distribute application data.
-
--   **[Caches](caches.html)**
-
-    The cache is the entry point to native client data caching in Geode. Through the cache, native clients gain access to the Geode caching framework for data loading, distribution, and maintenance.
-
--   **[Cache Initialization File (cache.xml)](../cache-init-file/chapter-overview.html)**
-
-    To ease the task of managing the structure of the cache, you can define the default Geode cache structure in an XML-based initialization file.
-
--   **[Regions](regions.html)**
-
-    You create cache regions either programmatically or through declarative statements in the `cache.xml` file. Generally, a cache is organized and populated through a combination of the two approaches.
-
--   **[Region Entries](entries.html)**
-
-    Region entries hold cached application data. Entries are automatically managed according to region attribute settings.
-
--   **[Region Consistency](consistency_checking_in_regions.html)**
-
-    Geode ensures that all copies of a region eventually reach a consistent state on all members and clients that host the region.
-
--   **[Region Attributes](region-attributes.html)**
-
-    Region attributes govern the automated management of a region and its entries.
-
--   **[Cache Management](cache-management.html)**
-
-    This section covers cache management.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/client-to-server-connection.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/client-to-server-connection.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/client-to-server-connection.html.md.erb
deleted file mode 100644
index c0a77ac..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/client-to-server-connection.html.md.erb
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title:  Client-to-Server Connection Process
----
-
-It is important to understand the sequence of events that occur when the native client connects with a Geode cache server.
-
-<a id="client-to-server-connection__section_C1E805D842FD44B984041C2ED1D4C2EF"></a>
-
-1.  A native client region is configured in `cache.xml` or programmatically with a set of server connection endpoints. Server endpoints identify each cache server by specifying the server's name and port number.
-
-    Client threads obtain, use, and release a connection to a connection pool that maintains new connections. The number of connections that a client can establish is governed by the pool's `min-connections` and `max-connections` settings, either using client XML configuration or programmatically through the `CacheFactory::setMinConnections()` and `CacheFactory::setMaxConnections()` APIs. The defaults for `min-connections` is 1 and `max-connections` is -1 meaning the connection count can grow to accommodate the number of active threads performing region operations.
-
-    This example shows how to use `cache.xml` to configure a native client region with endpoints set to two cache servers:
-
-    ``` pre
-    <pool name="examplePool" subscription-enabled="true" >
-        <server host="java_servername1" port="java_port1" />
-        <server host="java_servername2" port="java_port2" />
-    </pool>
-    <region name="NativeClientRegion" refid="CACHING_PROXY">
-        <region-attributes pool-name="examplePool"/>
-    </region>
-    ```
-    TCP connections on the native client are specified at the cache level, or by overriding endpoints for specific regions. The connections are created as the regions are created. In addition, connections can also get created for querying without having any created regions. In this case, when endpoints are defined at the cache level no regions are yet created and a query is fired.
-
-    You can configure client-server connections in two ways. Use either the region/cache endpoints or the Pool API. For more information about the pool API, see [Using Connection Pools](../connection-pools/connection-pools.html).
-
-2.  The client announces to the server which entries it wishes to have updated by programmatically registering interest in those entries. See [Registering Interest for Entries](registering-interest-for-entries.html) for more information.
-
-3.  The client `cache.xml` file should have the following parameters configured so the client can update the server and the client can receive updates from the server:
-    -   Caching enabled in the client region, by using the `CACHING_PROXY RegionShortcut` setting in the region attribute `refid`. A listener could also be defined so event notification occurs. You can use both, but at least one of the two methods must be used by the client to receive event notifications.
-    -   Set `subscription-enabled` to `true` so the client receives update notifications from the server for entries to which it has registered interest.
-
-4.  A native client application calls the C++ or .NET API to connect to a cache server.
-5.  The client and the cache server exchange a handshake over a configured endpoint to create a connection.
-6.  Any `create`, `put`, `invalidate`, and `destroy` events sent to the server are propagated across the distributed cache so the client can receive the events.
-
-**Note:**
-You may be able to improve system performance by making adjustments to the cache server.

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/closing-cache.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/closing-cache.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/closing-cache.html.md.erb
deleted file mode 100644
index f943f6f..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/closing-cache.html.md.erb
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title:  Closing the Cache
----
-
-Use the `Cache::close` function to release system resources when you finish using the cache.
-
-After the cache is closed, any further method calls on the cache or any region object result in a `CacheClosedException` .
-
-If the cache is in a durable client, you need to use the `keepalive` version of the close method. See [Disconnecting From the Server](../preserving-data/disconnecting-from-server.html).
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/concurrency-checks-enabled.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/concurrency-checks-enabled.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/concurrency-checks-enabled.html.md.erb
deleted file mode 100644
index 42085f5..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/concurrency-checks-enabled.html.md.erb
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title:  ConcurrencyChecksEnabled
----
-
-This attribute determines whether members perform checks to provide consistent handling for concurrent or out-of-order updates to distributed regions.
-
-A client cache can disable consistency checking for a region even if server caches enable consistency checking for the same region. This configuration ensures that the client sees all events for the region, but it does not prevent the client cache region from becoming out-of-sync with the server cache.
-
-Optionally enable concurrency checks for the region. Example:
-
-``` pre
-<region-attributes concurrency-checks-enabled="true"> 
-</region-attributes>
-```
-
-See [Region Consistency](consistency_checking_in_regions.html) for more information.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/concurrency-level.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/concurrency-level.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/concurrency-level.html.md.erb
deleted file mode 100644
index 08e0582..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/concurrency-level.html.md.erb
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title:  ConcurrencyLevel
----
-
-<a id="concurrency-level__section_20FB0B9EEE9442BAAD87E3C488610866"></a>
-This attribute estimates the maximum number of application threads that concurrently access a region entry at one time. This attribute helps optimize the use of system resources and reduce thread contention.
-
-The following declaration sets the region's `ConcurrencyLevel` to `16`:
-
-``` pre
-<region-attributes concurrency-level="16">
-</region-attributes>
-```
-
-**Note:**
-When `CachingEnabled` is `false`, do not set the `ConcurrencyLevel` attribute. An `IllegalStateException` is thrown if the attribute is set.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/consistency_checking_in_regions.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/consistency_checking_in_regions.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/consistency_checking_in_regions.html.md.erb
deleted file mode 100644
index d1a6ca5..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/consistency_checking_in_regions.html.md.erb
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title:  Region Consistency
----
-
-Geode ensures that all copies of a region eventually reach a consistent state on all members and clients that host the region.
-
-By default Geode members perform consistency checks when they apply updates to a distributed region, in order to ensure that all copies of the region eventually become consistent on all Geode members and client caches that host the region. Different types of region ensure consistency using different techniques. However, when consistency checking is enabled (the default) all entries in a region require additional overhead in order to store version and timestamp information.
-
-Although a region must have the same consistency checking configuration on all Geode members that host the region, you can optionally disable consistency checking in a client cache region while leaving consistency checking enabled for the region on Geode members. This configuration may be necessary in certain cases where the client must view all updates to a given region, even when Geode members discards an update in order to preserve region consistency.
-
-See [Consistency for Region Updates](geodeman/developing/distributed_regions/region_entry_versions.html#topic_CF2798D3E12647F182C2CEC4A46E2045) for more information.
-
-## <a id="concept_77340A4999AC4861972A0EE10303E557__section_167CD194A5374C64B4064783490F3EA8" class="no-quick-link"></a>Native Client Overhead for Consistency Checks
-
-In the native client regions, the overhead for performing consistency check is an additional 11 bytes per region entry. This overhead is slightly smaller than the overhead required to provide consistency checking on server-side region entries.
-
-If you cannot support the additional overhead in your deployment, you can disable consistency checks by setting the region attribute `concurrency-checks-enabled` to false for each region hosted by your client.

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/controlling-cache-size.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/controlling-cache-size.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/controlling-cache-size.html.md.erb
deleted file mode 100644
index e67b5ac..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/controlling-cache-size.html.md.erb
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title:  Controlling Cache Size
----
-
-You can control cache size through region size limits, cache size limits, or a combination of the two.
-
-<a id="controlling-cache-size__section_A0C25D6D1D5243778800AE67CAD8CB2C"></a>
-Geode controls region size by moving least recently used (LRU) entries from the region or from all cache regions.
-
-## <a id="controlling-cache-size__section_3C7994A4C9D9468F860D99C0ED086D74" class="no-quick-link"></a>Controlling Region Size
-
-You can cap the size of any region with the region attribute [LruEntriesLimit](lru-entries-limit.html#concept_75D723D60E044FF9AE97C939699AB10A). You can specify whether to destroy the entries or overflow them to disk in the attribute [DiskPolicy](disk-policy.html#disk-policy). If you overflow entries to disk, you must also specify the attribute [PersistenceManager](persistence-manager.html#persistence-manager).
-
-## <a id="controlling-cache-size__section_E59CA4D5724147DC83E8991E654AC155" class="no-quick-link"></a>Controlling Cache Size
-
-You can control overall cache size with the [heap-lru-limit](../setting-properties/attributes-gfcpp.html#attributes-gfcpp), which is set in `gfcpp.properties`. This property sets the maximum amount of memory used for the cache, in megabytes. If a new entry causes memory to grow past this limit, the LRU algorithm is called to evict entries. Heap LRU causes eviction to occur on all regions in the cache, overriding region-level [LruEntriesLimit](lru-entries-limit.html#concept_75D723D60E044FF9AE97C939699AB10A) settings when it needs to reclaim memory.
-
-For each region, evictions are performed according to the region's `DiskPolicy` and `PersistenceManager` settings. If you use `heap-lru-limit`, review these region attributes for all your caching regions, to be sure you are evicting the way you want to.
-
-The related [heap-lru-delta](../setting-properties/attributes-gfcpp.html#attributes-gfcpp) property, also set in `gfcpp.properties`, is the amount of memory to free up once the LRU evictions have begun. Memory is reclaimed until the amount of memory used is below `heap-lru-limit` minus `heap-lru-delta`.

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/create-access-cache.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/create-access-cache.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/create-access-cache.html.md.erb
deleted file mode 100644
index aab923c..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/create-access-cache.html.md.erb
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title:  Creating and Accessing a Cache
----
-
-When you create a native client cache, you are creating a native client cache instance. You must provide some basic configuration information such as a connection name and cache initialization parameters for the native client's cache instance.
-
-When you create a cache, you provide the following input:
-
--   **Connection name**. Used in logging to identify both the distributed system connection and the cache instance. If you do not specify a connection name, a unique (but non-descriptive) default name is assigned.
--   **`cache.xml` to initialize the cache (if the initialization is not done programmatically)**. To modify the cache structure, edit `cache.xml` in your preferred text editor. No changes to the application code are required. If you do not specify a cache initialization file, you need to initialize the cache programmatically.
-
-The `cache.xml` file contains XML declarations for cache, region, and region entry configuration.
-
-This XML declares server connection pools and regions:
-
-``` pre
-<cache>
-  <region name="clientRegion1" refid="PROXY">
-    <region-attributes pool-name="serverPool1"/>
-  </region>
-  <region name="clientRegion2" refid="PROXY">
-    <region-attributes pool-name="serverPool2"/>
-  </region>
-  <region name="localRegion3" refid="LOCAL"/>
-  <pool name="serverPool1">
-    <locator host="host1" port="40404"/>
-  </pool>
-  <pool name="serverPool2">
-    <locator host="host2" port="40404"/>
-  </pool>
-</cache>
-    
-```
-
-When you use the regions, the client regions connect to the servers through the pools named in their configurations.
-
-This file can have any name, but is generally referred to as `cache.xml` .
-
-For a list of the parameters in the `cache.xml` file, including the DTD, see [Cache Initialization File](../cache-init-file/chapter-overview.html).
-
-To create your cache, call the `CacheFactory create` function.
-
-The `cache` object it returns gives access to the native client caching API. For example:
-
-``` pre
-CacheFactoryPtr cacheFactory = CacheFactory::createCacheFactory();
-CachePtr cachePtr = cacheFactory->create();
-    
-```
-
-**Note:** For more information on how to create a cache, see the [Pivotal GemFire Native Client C++ API section on creating a cache](../cpp-caching-api/creating-cache.html) or the [Pivotal GemFire Native Client .NET API section on creating a cache](../dotnet-caching-api/creating-a-cache.html).
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/declarative-region-creation.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/declarative-region-creation.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/declarative-region-creation.html.md.erb
deleted file mode 100644
index 29986fb..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/declarative-region-creation.html.md.erb
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title:  Declarative Region Creation
----
-
-Declarative region creation involves placing the region's XML declaration, with the appropriate attribute settings, in the `cache.xml` file that is loaded at cache creation.
-
-**Note:**
-Before creating a region, specify region attributes. See [Region Attributes](region-attributes.html).
-
-Regions are placed inside the cache declaration in `region` elements. For example:
-
-``` pre
-<cache>
-  <pool name="examplePool" subscription-enabled="true" >
-    <server host="localhost" port="40404" />
-  </pool>
-  <region name="A" refid="PROXY">
-    <region-attributes pool-name="examplePool"/>
-  </region>
-  <region name="A1">
-    <region-attributes refid="PROXY" pool-name="examplePool"/>
-  </region>
-  <region name="A2" refid="CACHING_PROXY">
-    <region-attributes pool-name="examplePool">
-      <region-time-to-live>
-        <expiration-attributes timeout="120" action="invalidate"/>
-      </region-time-to-live>
-    </region-attributes>
-  </region>
-</cache>
-    
-```
-
-The `cache.xml` file contents must conform to the DTD provided in the <code>_product-dir_/dtd/gfcpp-cache8000.dtd</code> file. For details, see [Cache Initialization File](../cache-init-file/chapter-overview.html).
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/disk-policy.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/disk-policy.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/disk-policy.html.md.erb
deleted file mode 100644
index d862004..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/disk-policy.html.md.erb
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title:  DiskPolicy
----
-
-<a id="disk-policy__section_F3A921FC67B44DD795BD9B5C180FCBB1"></a>
-If the `lru-entries-limit` attribute is greater than zero, the optional `disk-policy` attribute determines how over-limit LRU entries are handled. LRU entries over the limit are either destroyed by default (`disk-policy` is none ) or written to disk (`overflows`).
-
-**Note:**
-If `LruEntriesLimit` is `0`, or `CachingEnabled` is `false`, do not set the `disk-policy` attribute. An `IllegalStateException` is thrown if the attribute is set.
-
-This declaration causes LRU to overflow to disk:
-
-``` pre
-<region-attributes lru-entries-limit="20000"
-    disk-policy="overflows">
-  <persistence-manager ... />
-</region-attributes>
-```
-
-Overflow requires a persistence manager for cache-to-disk and disk-to-cache operations. See [PersistenceManager](persistence-manager.html#persistence-manager).
-
-## <a id="disk-policy__section_FE325E59644149ACA43DA2ABB4CF0F7A" class="no-quick-link"></a>Overflowing Data to Disk
-
-Region data can be stored to disk using the overflow process to satisfy region capacity restrictions without completely destroying the local cache data. The storage mechanism uses disk files to hold region entry data. When an entry is overflowed, its value is written to disk but its key and entry object remain in the cache. This also uses the region attribute [DiskPolicy](disk-policy.html#disk-policy).
-
-Overflow allows you to keep the region within a user-specified size in memory by relegating the values of least recently used (LRU) entries to disk. Overflow essentially uses disk as a swap space for entry values. When the region size reaches the specified threshold, entry values are moved from memory to disk, as shown in the following figure. If an entry is requested whose value is only on disk, the value is copied back into memory, possibly causing the value of a different LRU entry to be overflowed to disk.
-
-<a id="disk-policy__fig_67963EC3BDD64272BBDAD9517E1D78A0"></a>
-
-<span class="figtitleprefix">Figure: </span>Data Flow Between Overflow Region and Disk Files
-
-<img src="../common/images/client-cache-data-flow.gif" alt="Data Flow Between Overflow Region and Disk Files" id="disk-policy__image_687021ECD97A40FB843DBDE59C555384" class="image" />
-
-In this figure the value of the LRU entry X has been moved to disk to recover space in memory. The key for the entry remains in memory. From the distributed system perspective, the value on disk is as much a part of the region as the data in memory. A `get` performed on region B looks first in memory and then on disk as part of the local cache search.

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/entries.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/entries.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/entries.html.md.erb
deleted file mode 100644
index 84780f2..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/entries.html.md.erb
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title:  Region Entries
----
-
-Region entries hold cached application data. Entries are automatically managed according to region attribute settings.
-
-You can create, update, invalidate, and destroy entries through explicit API calls or through operations distributed from other caches.
-
-When the number of entries is very large, a partitioned region can provide the required data management capacity if the total size of the data is greater than the heap in any single JVM.
-
-When an entry is created, a new object is instantiated in the region containing:
-
--   The entry key.
--   The entry value. This is the application data object. The entry value may be set to `NULL`, which is the equivalent of an invalid value.
-
-Entry operations invoke callbacks to user-defined application plug-ins. In this chapter, the calls that may affect the entry operation itself (by providing a value or aborting the operation, for example) are highlighted, but all possible interactions are not listed. For details of plug-ins, see the [Overview of Application Plug-Ins](application-plugins.html#application-plugins__section_8FEB62EEC7A042E0A85E0FEDC9F71597).
-
-`DateTime` objects must be stored in the cache in UTC, so that times correspond between client and server. If you use a date with a different time zone, convert it when storing into and retrieving from the cache.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/expiration-attributes.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/expiration-attributes.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/expiration-attributes.html.md.erb
deleted file mode 100644
index d154d62..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/expiration-attributes.html.md.erb
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title:  Specifying Expiration Attributes
----
-
-<a id="expiration-attributes__section_4901B92DE7EB408F81792920C9E4ED7C"></a>
-Expiration attributes govern the automatic eviction of regions and region entries from the cache. Eviction is based on the time elapsed since the last update or access to the object. This is referred to as the least-recently-used (LRU) eviction process. Expiration options range from marking the expired object as invalid to completely removing it from the distributed cache. Eviction can help keep data current by removing outdated entries, prompting a reload the next time they are requested. Eviction may also be used to recover space in the cache by clearing out unaccessed entries and regions.
-
-Similar to application plug-ins, expiration activities are hosted by each application that defines a region in its cache.
-
-The following example shows a declaration that causes the region's entries to be invalidated in the local cache after they have not been accessed for one minute.
-
-``` pre
-<region-attributes>
-    <entry-idle-time>
-        <expiration-attributes timeout="60" action="local-invalidate"/>
-    </entry-idle-time>
-</region-attributes>
-```
-
-Region and region entry expiration attributes are set at the region level. By default, regions and entries do not expire. The following attributes cover two types of expiration: time-to-live (TTL) and idle timeout.
-
-<table>
-<colgroup>
-<col width="50%" />
-<col width="50%" />
-</colgroup>
-<tbody>
-<tr class="odd">
-<td><code class="ph codeph">RegionTimeToLive</code></td>
-<td>Number of seconds that the region remains in the cache after the last creation or update before the expiration action occurs.</td>
-</tr>
-<tr class="even">
-<td><code class="ph codeph">EntryTimeToLive</code></td>
-<td>For entries, the counter is set to zero for <code class="ph codeph">create</code> and <code class="ph codeph">put</code> operations. Region counters are reset when the region is created and when an entry has its counter reset. An update to an entry causes the time-to-live (TTL) counters to be reset for the entry and its region.</td>
-</tr>
-<tr class="odd">
-<td><code class="ph codeph">RegionIdleTimeout</code></td>
-<td>Number of seconds that the region remains in the cache after the last access before the expiration action occurs.</td>
-</tr>
-<tr class="even">
-<td><code class="ph codeph">EntryIdleTimeout</code></td>
-<td>The idle timeout counter for an object is reset when its TTL counter is reset. An entry's idle timeout counter is also reset whenever the entry is accessed through a <code class="ph codeph">get</code> operation.
-<p>The idle timeout counter for a region is reset whenever the idle timeout is reset for one of its entries.</p></td>
-</tr>
-</tbody>
-</table>
-
-## <a id="expiration-attributes__section_F338C1117B7B44398F59523B881EDD55" class="no-quick-link"></a>Using Statistics to Measure Expiration
-
-Expiration is measured by comparing expiration attribute settings with the last accessed time and last modified time statistics. These statistics are directly available to applications through the `CacheStatistics` object that is returned by the `Region::getStatistics` and `RegionEntry::getStatistics` functions. The `CacheStatistics` object also provides a function for resetting the statistics counters.
-
-## <a id="expiration-attributes__section_6B402F97ECD8492A8798AC838D0BB606" class="no-quick-link"></a>Expiration Actions
-
-You can specify one of the following actions for each expiration attribute:
-
--   **Destroy**. Removes the object completely from the cache. For regions, all entries are destroyed as well. Destroy actions are distributed according to the region's distribution settings.
--   **Invalidate**. Marks the object as invalid. For entries, the value is set to `NULL`. You invalidate a region by invalidating all its entries. Invalidate actions are distributed according to the region's distribution settings. When an entry is invalid, a `get` causes the cache to retrieve the entry according to the steps described in [Entry Retrieval](accessing-entries.html#accessing-entries__section_AD6AFD842C144C128FA1C7F0B9283372).
--   **Local destroy**. Destroys the object in the local cache but does not distribute the operation.
--   **Local invalidate**. Invalidates the object in the local cache but does not distribute the operation.
-    **Note:**
-    Destruction and invalidation cause the same event notification activities whether carried out explicitly or through expiration activities.
-
-## <a id="expiration-attributes__section_57F5B32CE9B34F29907E8697F51817F9" class="no-quick-link"></a>Region Expiration
-
-Expiration activities in distributed regions can be distributed or performed only in the local cache. So one cache could control region expiration for a number of caches in the distributed system.

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/getting-the-region-size.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/getting-the-region-size.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/getting-the-region-size.html.md.erb
deleted file mode 100644
index d7d80d8..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/getting-the-region-size.html.md.erb
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title:  Getting the Region Size
----
-
-The `Region` API provides a `size` method (`Size` property for .NET) that gets the size of a region.
-
-For native client regions, this gives the number of entries in the local cache, not on the servers.
-
-See the `Region` API documentation for details.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/initial-capacity.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/initial-capacity.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/initial-capacity.html.md.erb
deleted file mode 100644
index 18f96d9..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/initial-capacity.html.md.erb
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title:  InitialCapacity
----
-
-<a id="initial-capacity__section_AB0163B072DA4DA0B858293CA02E91A1"></a>
-Use this attribute, together with the `LoadFactor` attribute, to set the initial parameters on the underlying hashmap that stores region entries. This is the number of entries that the region map will be ready to hold when it is created.
-
-This declaration sets the region's initial capacity to `10000`:
-
-``` pre
-<region-attributes initial-capacity="10000">
-</region-attributes>
-```
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/invalidating-cached-entries.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/invalidating-cached-entries.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/invalidating-cached-entries.html.md.erb
deleted file mode 100644
index e13ac0b..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/invalidating-cached-entries.html.md.erb
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title:  Invalidating or Destroying Cached Entries
----
-
-<a id="invalidating-cached-entries__section_9244FABA5204452A8D25D1184310B7EE"></a>
-Invalidating an entry sets the entry's value to `NULL`. Destroying it removes the entry from the region altogether. These operations can be carried out in the local cache in the following ways:
-
--   Through direct API calls from the client.
--   Through expiration activities based on the entry's statistics and the region's attribute settings.
-
-**Note:**
-A user-defined cache writer is called before an operation is completed, and can abort an entry destroy operation.
-
-Whether carried out explicitly or through expiration activities, invalidation and destruction cause event notification: The `CacheEvent` object has an `isExpiration` flag that is set to true for events resulting from expiration activities, and set to `false` for all other events.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/invalidating-region.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/invalidating-region.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/invalidating-region.html.md.erb
deleted file mode 100644
index 3c1ab26..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/invalidating-region.html.md.erb
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title:  Invalidating and Destroying Regions
----
-
-Invalidation marks all entries contained in the region as invalid (with null values). Destruction removes the region and all of its contents from the cache.
-
-<a id="invalidating-region__section_6F7E304D1D5743F1B53FCBD4F82651D0"></a>
-You can execute these operations explicitly in the local cache in the following ways:
-
--   Through direct API calls from the native client.
--   Through expiration activities based on the region's statistics and attribute settings.
-
-In either case, you can perform invalidation and destruction as a local or a distributed operation.
-
--   A local operation affects the region only in the local cache.
--   A distributed operation works first on the region in the local cache and then distributes the operation to all other caches where the region is defined. This is the proper choice when the region is no longer needed, or valid, for any application in the distributed system.
--   If the region on the server is configured as a partitioned region, it cannot be cleared using API calls from the native client.
-
-A user-defined cache writer can abort a region destroy operation. Cache writers are synchronous listeners with the ability to abort operations. If a cache writer is defined for the region anywhere in the distributed system, it is invoked before the region is explicitly destroyed.
-
-Region invalidation and destruction can cause other user-defined application plug-ins to be invoked as well. These plug-ins are described in detail in the [Overview of Application Plug-Ins](application-plugins.html#application-plugins__section_8FEB62EEC7A042E0A85E0FEDC9F71597).
-
-
-Whether carried out explicitly or through expiration activities, invalidation and destruction cause event notification.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/load-factor.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/load-factor.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/load-factor.html.md.erb
deleted file mode 100644
index 7643702..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/load-factor.html.md.erb
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title:  LoadFactor
----
-
-<a id="load-factor__section_D4102F0D396E4E2DA05654A20FA0723D"></a>
-Use this attribute, together with the `InitialCapacity` attribute, to set the initial parameters on the underlying hashmap that stores region entries. When the number of entries in the map exceeds the `LoadFactor` times current capacity, the capacity is increased and the map is rehashed. You get the best performance if you configure a properly sized region at the start and do not have to rehash it.
-
-This declaration sets the region's load factor to `0.75` :
-
-``` pre
-<region-attributes load-factor="0.75">
-</region-attributes>
-```
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/lru-entries-limit.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/lru-entries-limit.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/lru-entries-limit.html.md.erb
deleted file mode 100644
index b73130a..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/lru-entries-limit.html.md.erb
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title:  LruEntriesLimit
----
-
-<a id="concept_75D723D60E044FF9AE97C939699AB10A__section_B0174EA802CB47C9981EF3BDF4B7D169"></a>
-This attribute sets the maximum number of entries to hold in a caching region. When the capacity of the caching region is exceeded, a least-recently-used (LRU) algorithm is used to evict entries.
-
-**Note:**
-This is a tuning parameter that affects system performance.
-
-When eviction is configured, memory consumption or entry count is monitored and, when capacity is reached, Geode makes way for new entries by removing or overflowing the stalest LRU entries to disk.
-
-If you use disk data overflow to supplement memory for your data cache, make sure you have enough disk space to store the data.
-
-This declaration limits the region to 20,000 entries:
-
-``` pre
-<region-attributes lru-entries-limit="20000"
-     initial-capacity="20000"
-     load-factor="1">
-</region-attributes>
-```
-
-Evicted entries can be destroyed or moved to disk as an extension of the cache. See [DiskPolicy](disk-policy.html#disk-policy).
-
-**Note:**
-When `CachingEnabled` is `false`, do not set the `LruEntriesLimit` attribute. An `IllegalStateException` is thrown if the attribute is set.
-
-See also [Controlling Cache Size](controlling-cache-size.html).
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/managing-lifetime-cached-object.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/managing-lifetime-cached-object.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/managing-lifetime-cached-object.html.md.erb
deleted file mode 100644
index 5d39ca9..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/managing-lifetime-cached-object.html.md.erb
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title:  Managing the Lifetime of a Cached Object
----
-
-All cacheable objects derive from `SharedBase` , which provides reference counting. Cacheable objects are referenced using `SharedPtr` types.
-
-<a id="managing-lifetime-cached-object__section_5F8E6FE4F9AB4C658516DB0D31DD4FF8"></a>
-When `SharedPtr` retrieves a cached object, the object remains alive as long as that pointer or the cache itself references the object.
-
-A native client may have many pointers that reference an object. Regardless of how many pointers to the object are deleted, the object remains alive until the last remaining pointer is deleted. At that point the object is deleted.
-
-This is a very simple example:
-
-``` pre
-CacheableStringPtr p = CacheableString::create("string");
-region.put("key", p) ;
-```
-
-In the example:
-
--   The act of object creation allocates memory and initializes the object.
--   When you assign the object to a `SharedPtr` , you relinquish control of the lifetime of that object to the reference counting mechanism for the cache.
--   The put operation does not actually copy the object into the cache. Rather, it copies a `SharedPtr` into the cache's hashmap. Consequently, the object remains alive in the cache when the original `SharedPtr` goes away.
-
-The client can make use of an object after you have initialized the object. For example, another `SharedPtr` might issue a `get` to retrieve the object from the cache:
-
-``` pre
-CacheableStringPtr p2 = region.get("key");
-```
-
-Because `p` (the original `SharedPtr`) and `p2` point to the same object in memory, it is possible under some circumstances for multiple `SharedPtr` types to work on the same object in data storage.
-
-**Note:**
-Once you have put an object into the cache, do not delete it explicitly. Attempting to do so can produce undesirable results.
-
-## <a id="managing-lifetime-cached-object__section_8753DE6DF3864BEC806D39F623CBE3E0" class="no-quick-link"></a>Changed Objects
-
-If an object update is received, the cache no longer holds the same object. Rather, it holds a completely different instance of the object. The client does not see the updates until it calls a `get` to fetch the object again from the local cache, or (in a cache plug-in) calls `EntryEvent::getNewValue`.
-
-For more about plug-ins, see [Overview of Application Plug-Ins](application-plugins.html#application-plugins__section_8FEB62EEC7A042E0A85E0FEDC9F71597).
-
-## <a id="managing-lifetime-cached-object__section_065526A7FFBB464591A5E119EB8D6CA6" class="no-quick-link"></a>Object Expiration
-
-When a cache automatically deletes an object as a result of an expiration action, the reference counting pointers protect the client from situations that might otherwise result if the cache actually freed the object's memory. Instead, the client disconnects the object from the cache by deleting the cache's `SharedPtr` reference, while leaving untouched any client threads with a `SharedPtr` to that object.
-
-## <a id="managing-lifetime-cached-object__section_6D700999EE534BD7999D5B428301F5A6" class="no-quick-link"></a>Object Lifetime Across the Distributed Cache
-
-An object remains alive until every copy of the object is gone. In distributed regions, expiration activities can be local or distributed, depending on a region's distribution settings. One cache could control the expiration of all copies of an object in all the caches in the distributed system. Alternatively, each cache could control the expiration of its own local copy of the object. If the configuration gives each cache local control, and the expiration parameters are set to different lengths of time in different caches, some copies of an object may still exist after it has disappeared in other caches. See [Specifying Expiration Attributes](expiration-attributes.html) for more information.

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/notification-for-operations.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/notification-for-operations.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/notification-for-operations.html.md.erb
deleted file mode 100644
index 0abfdcb..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/notification-for-operations.html.md.erb
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title:  Notification for Operations
----
-
-<a id="notification-for-operations__section_53F43C51118C4087915CB954CA3439E0"></a>
-Listeners are invoked for client-initiated operations only after the client operation succeeds on the server. Listener invocation on the client indicates that the server has the same data as the client.
-
-If a client operation fails on the server, the operation is rolled back, assuming that no other thread has modified the data in the intervening period. Rollback may not be possible in cases where the entry has been evicted by LRU or expiration during this period. Thus when an exception is received from the server for an operation, local changes may not have been rolled back
-
-## <a id="notification-for-operations__section_48240559E20D4FAF8FDEC8D62C098357" class="no-quick-link"></a>Event Notification Sequence
-
-Events received on the clients that originated on the server invoke the subscription for the event as seen by the server. Events originating on the client invoke the subscription as seen by the client.
-
-For example, a client that receives a `create` and an `update` from the server fires a `create` event and an `update` event because that is how the server saw it. A cacheless client that does two consecutive put operations has two `afterCreate` events invoked on the originating client because the client does not have any history about the first put , since it is cacheless.
-
-For the same sequence, the server sees an `afterCreate` and an `afterUpdate` event, and a remote client receiving the event sees an `afterCreate` followed by an `afterUpdate` event. A client that caches locally sees an `afterCreate` and an `afterUpdate` for the same scenario (as will the server and remote clients).

http://git-wip-us.apache.org/repos/asf/geode-native/blob/87b6e035/geode-docs/docs/geode-native-docs/client-cache/overview-client-cache.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/docs/geode-native-docs/client-cache/overview-client-cache.html.md.erb b/geode-docs/docs/geode-native-docs/client-cache/overview-client-cache.html.md.erb
deleted file mode 100644
index cd80d2c..0000000
--- a/geode-docs/docs/geode-native-docs/client-cache/overview-client-cache.html.md.erb
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title:  About the Native Client Cache
----
-
-The cache consists of data regions, each of which can contain any number of entries. Region entries hold the cached data. Every entry has a key that uniquely identifies it within the region and a value where the data object is stored.
-
-The `Cache` instance allows your process to set general parameters for communication between a cache and other caches in the distributed system, and to create and access any region in the cache.
-
-Regions are created from the `Cache` instance. Regions provide the entry point to the interfaces for instances of `Region` and `RegionEntry`.
-
-## <a id="native-client-cache__section_A0F2E9EF30324736BD0D5F92FE3D1BD7" class="no-quick-link"></a>Main Features and Functionality
-
-The native client cache provides the following features and functionality.
-
--   Local and distributed data caching for fast access.
--   Data distribution between applications on the same or different platforms.
--   Local and remote data loading through application plug-ins.
--   Application plug-ins for synchronous and asynchronous handling of data events.
--   Automated and application-specific data eviction for freeing up space in the cache, including optional overflow to disk.
--   System message logging, and statistics gathering and archiving.
-
-For more information specific to your client programming language, see [Pivotal GemFire Native Client C++ API](../cpp-caching-api/cpp-caching-api.html#concept_CEC658A999414AC3A494578C214BF64E) and [Pivotal GemFire Native Client .NET Caching API](../dotnet-caching-api/dotnet-caching-api.html#concept_FC6776DCE6ED48B887A6137761104AA4).
-The API references are at [http://gemfire-apis.docs.pivotal.io](http://gemfire-apis.docs.pivotal.io).
-
-


Mime
View raw message