geode-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aba...@apache.org
Subject [59/73] [abbrv] geode-native git commit: GEODE-1964 Move doc files to geode-native subdirectory, add geode-native-book directory, update User Guide sources for donation 2
Date Tue, 14 Feb 2017 19:36:17 GMT
http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/connection-pools/native-client-pool-api.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/connection-pools/native-client-pool-api.html.md.erb b/geode-docs/nativeclient/connection-pools/native-client-pool-api.html.md.erb
deleted file mode 100644
index afd8f43..0000000
--- a/geode-docs/nativeclient/connection-pools/native-client-pool-api.html.md.erb
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title:  Native Client Pool API
----
-
-The Geode native client API allows your clients to create and manage connection pools. The server side does not have an API.
-
-This section lists the primary native client API for pool management. For complete information on the classes and interfaces described here, see the API documentation.
-
-**Note:**
-Only C\# versions of Pool API interfaces, classes, and methods are shown throughout the text in this section (example: `Pool.GetQueryService()`) . The code examples demonstrate both C++ and C\# versions.
-
-**Gemstone::GemFire::Cache**
-
--   `Pool` interface. API to retrieve pool attributes.
--   `PoolFactory` interface. API to configure pool attributes.
--   `PoolManager` interface. API to create a `PoolFactory` object and to find the pool objects.
--   `AttributesFactory` class. Has a new method `setPoolname` which assigns a pool to a region. Operations performed on the configured region use connections from the pool.
-
-**Note:**
-A region can have a pool attached to it. A pool may have multiple regions attached to it.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/connection-pools/running-connection-pool-code.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/connection-pools/running-connection-pool-code.html.md.erb b/geode-docs/nativeclient/connection-pools/running-connection-pool-code.html.md.erb
deleted file mode 100644
index 8ae4fcb..0000000
--- a/geode-docs/nativeclient/connection-pools/running-connection-pool-code.html.md.erb
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title:  Running the Connection Pool Code
----
-
-Examples demonstrate a simple procedure to create a pool factory and then create a pool instance in C++ and C\#. They also help you to execute a query.
-
-The examples create a pool with locators. Ensure that you create a pool with locators or endpoints, but not both. The first example demonstrates creating a pool by adding locators. The second example demonstrates creating a pool by adding servers. For more information, see the example in the QuickStart Guide.
-
-## Connection Pool Creation and Execution Using C++
-
-``` pre
-PropertiesPtr prptr = Properties::create();
-systemPtr = CacheFactory::createCacheFactory(prptr);
-
-cachePtr = systemPtr->create();
-PoolFactoryPtr poolFacPtr = PoolManager::createFactory();
-//to create pool add either endpoints or add locators or servers
-//pool with endpoint, adding to pool factory
-//poolFacPtr->addServer("localhost", 12345 /*port number*/);
-//pool with locator, adding to pool factory
-poolFacPtr->addLocator("localhost", 34756 /*port number*/);
-PoolPtr pptr = NULLPTR;
-if ((PoolManager::find("examplePool")) == NULLPTR) {
-  // Pool with this name does not exist
-  pptr = poolFacPtr->create("examplePool");
-}
-RegionFactoryPtr regionFactory =
-    cachePtr->createRegionFactory(CACHING_PROXY);
-regionPtr = regionFactory
-    ->setPoolName("examplePool")
-    ->create("regionName");
-QueryServicePtr qs = cachePtr->getQueryService("examplePool");
-```
-
-## Connection Pool Creation and Execution Using C\# .NET
-
-``` pre
-Properties prop = Properties.Create();
-CacheFactory cacheFactory = CacheFactory.CreateCacheFactory(prop);
-Cache cache = cacheFactory.Create();
-
-PoolFactory poolFact = PoolManager.CreateFactory();
-//to create pool add either endpoints or add locators
-//pool with endpoint, adding to pool factory.
-poolFact.AddServer("localhost", 40404 /*port number*/);
-//pool with locator, adding to pool factory
-//poolFact.AddLocator("hostname", 15000 /*port number*/);
-Pool pool = null;
-if (PoolManager.Find("poolName") == null) {
-  pool = poolFact.Create("poolName");
-}
-int loadConditInterval = pool.LoadConditioningInterval;
-RegionFactory regionFactory =
-    cache.CreateRegionFactory(RegionShortcut.CACHING_PROXY);
-IRegion<string, string> region =
-    regionFactory.SetPoolName(poolName).Create<string, string>(regionName);
-```
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/connection-pools/subscription-properties.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/connection-pools/subscription-properties.html.md.erb b/geode-docs/nativeclient/connection-pools/subscription-properties.html.md.erb
deleted file mode 100644
index 0e175ab..0000000
--- a/geode-docs/nativeclient/connection-pools/subscription-properties.html.md.erb
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title:  Subscription Properties
----
-
-Each connection pool has a single subscription connection that can be to any server that matches the requirements of the connection pool.
-
-When a client registers interest for a region, if the connection pool does not already have a subscription channel, the connection pool sends a message to the server locator, and the server locator chooses servers to host the queue and return those server names to the client. The client then contacts the chosen servers and asks them to create the queue.
-
-The client maintains at least one connection with each server hosting a queue. If the server does not detect any connections from a non-durable client, it drops the client queue and closes all artifacts for the client. For information about durable client subscriptions, see [Durable Client Messaging](../preserving-data/durable-client-messaging.html#concept_F88B659FB4324F599924F3F2933452B4).
-
-## <a id="subscription-properties__section_294BD33FBDC6454FAD9C5118829EBBA4" class="no-quick-link"></a>Requesting a Subscription Region Queue
-
-The client-to-server locator request is a short lived TCP request. The client sends a message with:
-
--   The client ID.
--   (Optional) target server group.
--   Number of redundant copies.
--   Servers to exclude from the results. This list is used if the client cannot connect to a server and needs to request a new one.
-
-The server locator responds with a list of servers. The client is responsible for contacting the primary and secondaries and asking them to host the queue.
-
-For durable subscriptions, the server locator must be able to locate the servers that host the queues for the durable client. When a durable client sends a request, the server locator queries all the available servers to see if they are hosting the subscription region queue for the durable client. If the server is located, the client is connected to the server hosting the subscription region queue.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/continuous-querying/1-how-cont-query-works.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/continuous-querying/1-how-cont-query-works.html.md.erb b/geode-docs/nativeclient/continuous-querying/1-how-cont-query-works.html.md.erb
deleted file mode 100644
index 3b2214b..0000000
--- a/geode-docs/nativeclient/continuous-querying/1-how-cont-query-works.html.md.erb
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title:  How Continuous Querying Works
----
-
-C++ and .NET clients register interest in events using simple query expressions. Events are sent to client listeners that you can program to do whatever your application requires.
-
--   [Overview of CQ Operations](1-how-cont-query-works.html#security__section_D4F0FAC4880A49A18D6E11B777C2716A)
--   [Logical Architecture and Data Flow](1-how-cont-query-works.html#security__section_9FEA0CFD3DA64BF5B42B37F5CE05C993)
--   [State and Life Cycle](1-how-cont-query-works.html#security__section_677EB38AB60E4410A8A60980CD3BAACB)
-
-## <a id="security__section_D4F0FAC4880A49A18D6E11B777C2716A" class="no-quick-link"></a>Overview of CQ Operations
-
-You subscribe to server-side events using SQL-type query filtering. The native client sends a query to the server side for execution and receives the events that satisfy the criteria.
-
-For example, in a region storing stock market trade orders, you can retrieve all orders over a certain price by running a CQ with a query like this:
-
-``` pre
-SELECT * FROM /tradeOrder t WHERE t.price > 100.00
-```
-
-When the CQ is running, the server sends the client all new events that affect the results of the query. On the native client side, listeners programmed by you receive and process incoming events. For the example query on `/tradeOrder`, you might program a listener to push events to a GUI where higher-priced orders are displayed. CQ event delivery uses the client/server subscription framework described in [Client to Server Connection Process](../client-cache/client-to-server-connection.html#client-to-server-connection).
-
-CQs do not update the native client region. This is in contrast to other server-to-client messaging, such as the updates sent to satisfy interest registration and responses to get requests from the client. CQs are notification tools for the CQ listeners, which can be programmed in any way your application requires.
-
-When a CQ is running against a server region, each entry event is evaluated against the CQ query by the thread that updates the server cache. If either the old or the new entry value satisfies the query, the thread puts a `CqEvent` in the client's queue. The `CqEvent` contains information from the original cache event, plus information specific to the CQ's execution. Once received by the client, the `CqEvent` is passed to the `onEvent` method of all `CqListeners` defined for the CQ.
-
-## <a id="security__section_9FEA0CFD3DA64BF5B42B37F5CE05C993" class="no-quick-link"></a>Logical Architecture and Data Flow
-
-Clients can execute any number of CQs, with each CQ given any number of listeners. This figure shows the logical architecture of continuous querying.
-
-<img src="../common/images/10-Continuous_Querying-1.gif" id="security__image_7B1C48755BE541BDBCD7DCD442728754" class="image" />
-
-The next figure shows the typical CQ data flow when entries are updated in the server cache. A description of the data flow follows, along with a description of CQ state and life cycle.
-
-<img src="../common/images/10-Continuous_Querying-3.gif" id="security__image_F5E03A24E29C41B683EC6E85B3B64977" class="image" />
-
-1.  Entry events come to the server's cache from any source: the server or its peers, distribution from remote sites, or updates from a client.
-2.  For each event, the server's CQ executor framework checks for a match with the CQs it has running.
-3.  If the old or new entry value satisfies a CQ query, a CQ event is sent to the CQ's listeners on the client side. Each listener for the CQ gets the event. In the preceding figure:
-    -   Both new and old prices for entry X satisfy the CQ query, so that event is sent indicating an update to the query results.
-    -   The old price for entry Y satisfied the query, so it was part of the query results. The invalidation of entry Y means that it does not satisfy the query. Because of this, the event is sent indicating that it is destroyed in the query results.
-    -   The price for the newly created entry Z does not satisfy the query, so no event is sent.
-
-The region operations do not translate directly to specific query operations, and the query operations do not specifically describe the region events. Instead, each query operation describes how its corresponding region event affects the query results. For more information, see [CqEvent Object](5c-cq-event-object.html#security).
-
-## <a id="security__section_677EB38AB60E4410A8A60980CD3BAACB" class="no-quick-link"></a>State and Life Cycle
-
-A CQ has three possible states that can be accessed from the client by calling `CqQuery.getState`.
-
--   `STOPPED`. The CQ has been created but not yet executed, or it has been explicitly stopped from executing. The stopped CQ uses system resources. You start or restart the CQ by calling the execute method on `CqQuery`.
--   `RUNNING`. The CQ is being executed on the server for all events in the region referenced by the query. Results are sent to all client listeners associated with the `CqQuery`.
--   `CLOSED`. The CQ is closed and is not using system resources. Invoking an `execute` or `stop` method on closed `CqQuery` throws an exception.
-
-**Typical CQ life cycle**
-
-1.  The client creates the CQ. This sets up everything for running the query and provides the client with a `CqQuery` object, but does not execute the CQ. At this point, the query is in a `STOPPED `state, ready to be closed or run.
-2.  The client runs the CQ with an API call to one of the `CqQuery execute*` methods. This puts the query into a `RUNNING` state on the client and on the server.
-3.  The CQ is closed by a client call to `CqQuery.close`. This de-allocates all resources in use for the CQ on the client and server. At this point, the cycle could begin again with the creation of a new `CqQuery` instance.
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/continuous-querying/2-config-for-continuous-querying.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/continuous-querying/2-config-for-continuous-querying.html.md.erb b/geode-docs/nativeclient/continuous-querying/2-config-for-continuous-querying.html.md.erb
deleted file mode 100644
index 5644a34..0000000
--- a/geode-docs/nativeclient/continuous-querying/2-config-for-continuous-querying.html.md.erb
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title:  Configuring Your System for Continuous Querying
----
-
-The continuous query (CQ) functionality requires standard client/server distributed system and cache configuration settings.
-
--   The client region must use a pool with subscription-enabled set to true .
--   If you want your CQs to be highly available, configure your servers for high availability as described in [Configuring Highly Available Servers](../../developing/events/configuring_highly_available_servers.html) in the *User's Guide*. When your servers are highly available, CQs are registered on primary and secondary servers, and server failover is performed without any interruption to CQ messaging. CQ events messaging uses the same queues used for server-to-client messaging.
-    **Note:**
-    When CQ is used with high availability, the overhead for CQs is higher than for the key-based interest list registration. CQs are executed on the primary and all secondary servers, so they require more overall server processing.
-
--   To obtain a list of all durable CQs registered on the server, use the `QueryService.getAllDurableCqsFromServer` API.
--   If you want your CQs to be durable, configure your native clients for durable messaging. When your clients are durable, you can create durable CQs whose events are maintained during client disconnects and replayed for the client when it reconnects. The process and data flow particular to durable CQs is described in [Durable Client Messaging](../preserving-data/durable-client-messaging.html#concept_F88B659FB4324F599924F3F2933452B4).
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/continuous-querying/3-native-client-cq-api.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/continuous-querying/3-native-client-cq-api.html.md.erb b/geode-docs/nativeclient/continuous-querying/3-native-client-cq-api.html.md.erb
deleted file mode 100644
index 46d66a9..0000000
--- a/geode-docs/nativeclient/continuous-querying/3-native-client-cq-api.html.md.erb
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title:  CQ API and Main Features
----
-
-This chapter documents the primary native client API for CQ management.
-
-The Apache Geode native client API allows your clients to create and manage CQs. (The server side does not have an API.) Continuous querying provides native client query syntax, events-based management, integration with client/server architecture, active query execution, and interest criteria based on data values. For complete information on the classes and interfaces described here, see the online API documentation.
-
--   [CQ API and Main Features](3-native-client-cq-api.html)
--   [Main Features of Continuous Querying](3-native-client-cq-api.html#security__section_74A3A0ECC2B645CEAEFDF68350E55EB4)
-
-**Gemstone::GemFire::Cache**
-
-Only C\# versions of CQ API interfaces, classes, and methods are shown here (example: `CqQuery.execute`). The code examples demonstrate both C++ and C\# versions.
-
--   `QueryService` interface. Provides methods that enable you to:
-    -   Create a new CQ and specify whether it is durable (available for durable clients)
-    -   Execute a CQ with or without an initial result
-    -   List all the CQs registered by the client
-    -   Close and stop CQs
-    -   Get a handle on `CqStatistics` for the client
-
-    You run `QueryService` CQ methods against the server cache. The QueryService can be obtained from the cache or from a pool.
--   `CqQuery`interface. Provides methods for managing a continuous query after it is created through the `QueryService`. This interface is used typically to begin and end CQ execution and to retrieve other CQ-related objects such as CQ attributes, CQ statistics, and CQ state.
--   `CqListener` application plug-in interface. Handles continuous query events after they occur. You program this interface.
--   `CqEvent`interface. Provides all information sent from the server about the CQ event, which is passed to the CQ's `CqListener` methods.
--   `CqState` interface. Provides information on the state of a `CqQuery`, through the getState method of the `CqQuery` instance.
--   `CqAttributes, CqAttributesFactory, CqAttributesMutator` interfaces. Allow you to manage CQ attributes. The attributes consist of `CqListener `plug-in specifications.
--   `CqStatistics, CqServiceStatistics` interfaces. Allow you to access statistics information for a single CQ and for the query service's management of CQs as a whole. For details on statistics, see [Statistics API](../cpp-caching-api/gfe-cpp-api.html#concept_AB12290E89CA4724AC9F51EFF7B8B8EA__section_42764C6327944514AE4A26684D7EBCB0).
-
-## <a id="security__section_74A3A0ECC2B645CEAEFDF68350E55EB4" class="no-quick-link"></a>Main Features of Continuous Querying
-
-Continuous querying in the native client has the following features:
-
--   **Standard Geode native client query syntax and semantics**. CQ queries are expressed in the same language used for other native client queries (see [Remote Querying.](../remote-querying/remote-querying.html#security)).
--   **Standard Geode events-based management of CQ events**. The event handling used to process CQ events is based on the standard Geode event handling framework. The CQListener interface is similar to [Application Plug-Ins](../client-cache/application-plugins.html#application-plugins) and [Application Callbacks](../dotnet-caching-api/application-callbacks.html#concept_E66738BC9B3B4E239D19ABFB198BE754).
--   **Complete integration with the client/server architecture**. CQ functionality uses existing server-to-client messaging mechanisms to send events. All tuning of your server-to-client messaging also tunes the messaging of your CQ events. If your system is configured for high availability then your CQs are highly available, with seamless failover provided in case of server failure (see [High Availability for Client-to-Server Communication](../preserving-data/high-availability-client-server.html#concept_F7A143F51EEA46B28AC612DEB7849D99)). If your clients are durable, you can also define any of your CQs as durable (see [Durable Client Messaging](../preserving-data/durable-client-messaging.html#concept_F88B659FB4324F599924F3F2933452B4)).
--   **Interest criteria based on data values**. CQ queries are run against the region's entry values. Compare this to register interest by reviewing [Registering Interest for Entries](../client-cache/registering-interest-for-entries.html#registering-interest-for-entries).
--   **Active query execution**. Once initialized, the queries only operate on new events instead of on the entire region data set. Events that change the query result are sent to the client immediately.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/continuous-querying/5-implementing-cq.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/continuous-querying/5-implementing-cq.html.md.erb b/geode-docs/nativeclient/continuous-querying/5-implementing-cq.html.md.erb
deleted file mode 100644
index 58351d6..0000000
--- a/geode-docs/nativeclient/continuous-querying/5-implementing-cq.html.md.erb
+++ /dev/null
@@ -1,47 +0,0 @@
----
-title:  Implementing a Continuous Query
----
-
-You can specify CQs for any client region.
-
-Here are the high-level steps for implementing a continuous query, with links to more detailed information in this chapter.
-
-1.  Make sure your system is configured properly to run CQs. See [Configuring for Continuous Querying](2-config-for-continuous-querying.html#security).
-2.  Decide what data to track on the server and write your queries. Use your criteria for tracking data changes to write your CQ queries. See [Writing the Continuous Query](5a-writing-cq.html#security).
-3.  Determine how to handle the CQ events on the client and write your listeners.
-
-    Each CQ can have any number of listeners. In addition to your core CQ listeners, you might have listeners that you use for all CQs to track statistics or other general information. See [Writing the CQ Listener](5b-writing-cq-listener.html#security).
-
-4.  Write the client code to put the queries and their listeners into named CQ queries and execute the queries. Make sure you close the queries if your client no longer needs them and when the client exits. See [Running the Continuous Query Code](5e-running-cq-code.html#security).
-5.  Write any code you need for monitoring and managing your CQ query. See [Managing Continous Queries](6-managing-cqs.html#security).
-6.  Run your code, monitor and tune as needed.
-
--   **[Configuring Your System for Continuous Querying](../../nativeclient/continuous-querying/2-config-for-continuous-querying.html)**
-
-    The continuous query (CQ) functionality requires standard client/server distributed system and cache configuration settings.
-
--   **[Writing the Continuous Query](../../nativeclient/continuous-querying/5a-writing-cq.html)**
-
-    Each CQ uses a query and any number of listeners. The query filters the events on the server and the listener handles the events that make it through the query filter. With the query and the listener in hand, you can create and execute your query through the API.
-
--   **[Writing the CQ Listener or CQ Status Listener](../../nativeclient/continuous-querying/5b-writing-cq-listener.html)**
-
-    The following C++ and .NET examples show how you might program a simple `CqListener` or `CqStatusListener` to update a display screen based on the CQ events it receives.
-
--   **[CqEvent Object](../../nativeclient/continuous-querying/5c-cq-event-object.html)**
-
-    The `CqEvent` object contains information about the CQ event.
-
--   **[Running the Continuous Query Code](../../nativeclient/continuous-querying/5e-running-cq-code.html)**
-
-    Create your CQ from an instance of the QueryService . Once created, the CQ is maintained primarily through the CqQuery interface. The following two C++ and C\# examples show the basic calls in the CQ life cycle.
-
--   **[CQ Execution Options](../../nativeclient/continuous-querying/5f-cq-execution-options.html)**
-
-    CQ execution can be done with or without an initial result set by calling `CqQuery.Execute` or `CqQuery.ExecuteWithInitialResults`. The initial `SelectResults` returned from `ExecuteWithInitialResults` is the same as the one you would get if you ran the query ad hoc by calling `QueryService.NewQuery.Execute` on the server cache, but with the key added.
-
--   **[When an Error Occurs in a Running CQ](../../nativeclient/continuous-querying/5d-when-error-occurs.html)**
-
-    When an error occurs in CQ execution on the server, specific information on the error itself is stored in the server's log file. An exception is passed to the client, and the client throws an exception.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/continuous-querying/5a-writing-cq.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/continuous-querying/5a-writing-cq.html.md.erb b/geode-docs/nativeclient/continuous-querying/5a-writing-cq.html.md.erb
deleted file mode 100644
index 1070b1f..0000000
--- a/geode-docs/nativeclient/continuous-querying/5a-writing-cq.html.md.erb
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title:  Writing the Continuous Query
----
-
-Each CQ uses a query and any number of listeners. The query filters the events on the server and the listener handles the events that make it through the query filter. With the query and the listener in hand, you can create and execute your query through the API.
-
-This is the basic syntax for the CQ query:
-
-``` pre
-SELECT * FROM /fullRegionPath [iterator] [WHERE clause]
-```
-
-The CQ query must satisfy the standard Geode native client querying specifications described in [Remote Querying](../remote-querying/remote-querying.html#security). It also must satisfy these restrictions:
-
--   The `FROM` clause must contain only a single region specification, with optional iterator variable.
--   The query must be a `SELECT` expression only, preceded by zero or more `IMPORT` statements. This means the query cannot be a statement like `/tradeOrder.name` or `(SELECT * from                     /tradeOrder).size`.
--   The CQ query cannot use:
-    -   Cross region joins
-    -   Drill-downs into nested collections
-    -   `DISTINCT`
-    -   Projections
-    -   Bind parameters
-
-Queries not meeting these constraints generate an `UnsupportedOperationException` from the `QueryServicenewCq` method.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/continuous-querying/5b-writing-cq-listener.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/continuous-querying/5b-writing-cq-listener.html.md.erb b/geode-docs/nativeclient/continuous-querying/5b-writing-cq-listener.html.md.erb
deleted file mode 100644
index 2e3c06e..0000000
--- a/geode-docs/nativeclient/continuous-querying/5b-writing-cq-listener.html.md.erb
+++ /dev/null
@@ -1,280 +0,0 @@
----
-title:  Writing the CQ Listener or CQ Status Listener
----
-
-The following C++ and C\# .NET examples show how you might program a simple `CqListener` or `CqStatusListener` to update a display screen based on the CQ events it receives.
-
-The listener retrieves the `queryOperation` and entry key and value from the `CqEvent` , then updates the screen according to the operation type provided in `queryOperation`.
-
-CQ events do not change your client cache. They are provided as an event service only. This allows you to have any collection of CQs without storing large amounts of data in your regions. If you need to persist information from CQ events, program your listener to store the information where it makes the most sense for your application.
-
-Be very careful if you choose to update your cache from your `CqListener`. If your listener updates the region that is queried in its own CQ, the update may be forwarded to the server. If the update on the server satisfies the same CQ, it may be returned to the same listener that did the update, which could put your application into an infinite loop. This same scenario could be played out with multiple regions and multiple CQs if the listeners are programmed to update each other's regions.
-
-## CqListener Implementation (C++)
-
-``` pre
-// CqListener class
-class TradeEventListener : public CqListener {
-   public:
-  void onEvent(const CqEvent& cqEvent) {
-    // Operation associated with the query op
-    CqOperation::CqOperationType queryOperation = cqEvent.getQueryOperation();
-    // key and new value from the event
-    CacheableKeyPtr key = cqEvent.getKey();
-    TradeOrderPtr tradeOrder = dynCast<TradeOrderPtr>(cqEvent.getNewValue());
-    if (queryOperation==CqOperation::OP_TYPE_UPDATE) {
-      // update data on the screen for the trade order
-      . . .
-    }
-    else if (queryOperation==CqOperation::OP_TYPE_CREATE) {
-     // add the trade order to the screen
-      . . .
-    }
-    else if (queryOperation==CqOperation::OP_TYPE_DESTROY) {
-    // remove the trade order from the screen
-      . . .
-   }
- }
- void onError(const CqEvent& cqEvent) {
-  // handle the error
- }
- void close() {
-  // close the output screen for the trades
-  . . .
- }
-}
-```
-
-## CqListener Implementation (C\# .NET)
-
-``` pre
-// CqListener class
-public class TradeEventListener : ICqListener {
-  public void onEvent(CqEvent cqEvent) {
-     // Operation associated with the query op
-     CqOperationType queryOperation = cqEvent.getQueryOperation();
-     // key and new value from the event
-     ICacheableKey key = cqEvent.getKey();
-     CacheableString keyStr = key as CacheableString;
-     IGFSerializable val = cqEvent.getNewValue();
-     TradeOrder tradeOrder = val as TradeOrder;
-     if (queryOperation==CqOperationType.OP_TYPE_UPDATE) {
-        // update data on the screen for the trade order
-        // . . .
-        }
-     else if (queryOperation== CqOperationType.OP_TYPE_CREATE) {
-        // add the trade order to the screen
-        // . . .
-     }
-     else if (queryOperation== CqOperationType.OP_TYPE_DESTROY) {
-        // remove the trade order from the screen
-        // . . .
-     }
-   }
-   public void onError(CqEvent cqEvent) {
-       // handle the error
-   }
-   // From CacheCallback
-   public void close() {
-      // close the output screen for the trades  
-      // . . .
-   }
-} 
-```
-
-## <a id="security__section_B80352FB8FC94C929C934598FE958692" class="no-quick-link"></a>Writing a CqStatusListener
-
-If you need your CQs to detect whether they are connected to any of the servers that host its subscription queues, implement a `CqStatusListener` instead of a `CqListener`.
-
-`CqStatusListener` extends the current `CqListener`, allowing a client to detect when a CQ is connected and/or disconnected from the server(s). The `onCqConnected()` method will be invoked when the CQ is connected, and when the CQ has been reconnected after being disconnected. The `onCqDisconnected()` method will be invoked when the CQ is no longer connected to any servers.
-
-Taking the examples from above, we can instead implement a `CqStatusListener`.
-
-When you install the `CqStatusListener`, your listener will be able to detect its connection status to the servers that it is querying.
-
-## CqStatusListener Implementation (C++)
-
-``` pre
-class MyCqStatusListener : public CqStatusListener {
-  uint8_t m_id;
-  uint32_t m_numInserts;
-  uint32_t m_numUpdates;
-  uint32_t m_numDeletes;
-  uint32_t m_numEvents;
-  uint32_t m_cqsConnectedCount;
-  uint32_t m_cqsDisconnectedCount;
-
-  public:
-  uint8_t getId()
-  {
-    return m_id;
-  }
-  uint32_t getNumInserts()
-  {
-    return m_numInserts;
-  }
-  uint32_t getNumUpdates()
-  {
-    return m_numUpdates;
-  }
-  uint32_t getNumDeletes()
-  {
-    return m_numDeletes;
-  }
-  uint32_t getNumEvents()
-  {
-    return m_numEvents;
-  }
-  uint32_t getCqsConnectedCount()
-  {
-    return m_cqsConnectedCount;
-  }
-  uint32_t getCqsDisConnectedCount()
-  {
-    return m_cqsDisconnectedCount;
-  }
-  MyCqStatusListener(uint8_t id):
-    m_id(id),
-    m_numInserts(0),
-    m_numUpdates(0),
-    m_numDeletes(0),
-    m_numEvents(0),
-    m_cqsDisconnectedCount(0),
-    m_cqsConnectedCount(0)
-  {
-  }
-  inline void updateCount(const CqEvent& cqEvent)
-  {
-    m_numEvents++;
-    switch (cqEvent.getQueryOperation())
-    {
-      case CqOperation::OP_TYPE_CREATE: {
-        m_numInserts++;
-        break;
-        }
-      case CqOperation::OP_TYPE_UPDATE: {
-        m_numUpdates++;
-        break;
-        }
-      case CqOperation::OP_TYPE_DESTROY: {
-        m_numDeletes++;
-        break;
-        }
-      default:
-        break;
-       }
-  }
-  void onEvent(const CqEvent& cqe){
-    updateCount(cqe);
-  }
-  void onError(const CqEvent& cqe){
-    updateCount(cqe);
-  }
-  void close(){
-  }
-  void onCqDisconnected() {
-    //This is called when the cq loses connection with all servers.
-    m_cqsDisconnectedCount++;
-  }
-  void onCqConnected() {
-    //This is called when the cq establishes a connection with a server.
-    m_cqsConnectedCount++;
-  }
-  void clear() {
-    m_numInserts = 0;
-    m_numUpdates = 0;
-    m_numDeletes = 0;
-    m_numEvents = 0;
-    m_cqsDisconnectedCount = 0;
-    m_cqsConnectedCount = 0;
-  }
-};
-```
-
-## CQStatusListener Implementation (C\# .NET)
-
-``` pre
-  public class MyCqStatusListener<TKey, TResult> : ICqStatusListener<TKey, TResult>
-  {
-    #region Private members
-    private bool m_failedOver = false;
-    private UInt32 m_eventCountBefore = 0;
-    private UInt32 m_errorCountBefore = 0;
-    private UInt32 m_eventCountAfter = 0;
-    private UInt32 m_errorCountAfter = 0;
-    private UInt32 m_CqConnectedCount = 0;
-    private UInt32 m_CqDisConnectedCount = 0;
-    #endregion
-
-    #region Public accessors
-    public MyCqStatusListener(int id)
-    {
-    }
-    public void failedOver()
-    {
-      m_failedOver = true;
-    }
-    public UInt32 getEventCountBefore()
-    {
-      return m_eventCountBefore;
-    }
-    public UInt32 getErrorCountBefore()
-    {
-      return m_errorCountBefore;
-    }
-    public UInt32 getEventCountAfter()
-    {
-      return m_eventCountAfter;
-    }
-    public UInt32 getErrorCountAfter()
-    {
-      return m_errorCountAfter;
-    }
-    public UInt32 getCqConnectedCount()
-    {
-      return m_CqConnectedCount;
-    }
-    public UInt32 getCqDisConnectedCount()
-    {
-      return m_CqDisConnectedCount;
-    }
-    #endregion
-
-    public virtual void OnEvent(CqEvent<TKey, TResult> ev)
-    {
-      if (m_failedOver == true)
-        m_eventCountAfter++;
-      else
-        m_eventCountBefore++;      
-    }
-    public virtual void OnError(CqEvent<TKey, TResult> ev)
-    {
-      if (m_failedOver == true)
-        m_errorCountAfter++;
-      else
-        m_errorCountBefore++;
-    }
-    public virtual void Close()
-    {
-    }
-    public virtual void OnCqConnected()
-    {
-      m_CqConnectedCount++;      
-    }
-    public virtual void OnCqDisconnected()
-    {
-      m_CqDisConnectedCount++;      
-    }
-    public virtual void Clear()
-    {
-      m_eventCountBefore = 0;
-      m_errorCountBefore = 0;
-      m_eventCountAfter = 0;
-      m_errorCountAfter = 0;
-      m_CqConnectedCount = 0;
-      m_CqDisConnectedCount = 0;
-    }
-  }
-```
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/continuous-querying/5c-cq-event-object.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/continuous-querying/5c-cq-event-object.html.md.erb b/geode-docs/nativeclient/continuous-querying/5c-cq-event-object.html.md.erb
deleted file mode 100644
index 1917675..0000000
--- a/geode-docs/nativeclient/continuous-querying/5c-cq-event-object.html.md.erb
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title:  CqEvent Object
----
-
-The `CqEvent` object contains information about the CQ event.
-
--   Entry key and new value.
--   Base operation that triggered the CQ event in the server.
--   `CqQuery` object associated with this CQ event.
--   Query operation associated with this CQ event. This operation describes the change affected to the query results by the cache event. Possible values are:
-    -   `CREATE`, which corresponds to the standard database `INSERT` operation.
-    -   ` UPDATE`
-    -   `DESTROY`, which corresponds to the standard database `DELETE` operation.
-
-<a id="security__section_A619799378B14214AF922D819907FF38"></a>
-This table describes the query operation based on whether the old and new entry values in the region entry event satisfy the query criteria.
-
-<a id="security__table_92A6A66523764199A19BCD66BA189921"></a>
-
-<table>
-<caption><span class="tablecap">Table 1. Query Operation Based on Old and New Entry Values</span></caption>
-<colgroup>
-<col width="33%" />
-<col width="33%" />
-<col width="33%" />
-</colgroup>
-<tbody>
-<tr class="odd">
-<td><strong>Old Entry Value</strong></td>
-<td><strong>New Entry Value</strong></td>
-<td><strong>Query Operation</strong></td>
-</tr>
-<tr class="even">
-<td>No value or value does not satisfy the query criteria.</td>
-<td>No value (operation is <code class="ph codeph">invalidate</code> or <code class="ph codeph">destroy</code>) or value does not satisfy the query.
-<p></p>
-<p>Value satisfies the query.</p></td>
-<td>N/A - no event
-<p></p>
-<p></p>
-<p><code class="ph codeph">create</code></p></td>
-</tr>
-<tr class="odd">
-<td>Value satisfies the query</td>
-<td>No value (operation is <code class="ph codeph">invalidate</code> or <code class="ph codeph">destroy</code>) or value does not satisfy the query.
-<p></p>
-<p>Value satisfies the query.</p></td>
-<td><code class="ph codeph">destroy</code>
-<p></p>
-<p></p>
-<p><code class="ph codeph">update</code></p></td>
-</tr>
-</tbody>
-</table>
-
-<span class="tablecap">**Table 1.** Query Operation Based on Old and New Entry Values</span>
-
-You can use the query operation to decide what to do with the `CqEvent` in your listeners. For example, a `CqListener` that displays query results on screen might stop displaying the entry, start displaying the entry, or update the entry display depending on the query operation.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/continuous-querying/5d-when-error-occurs.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/continuous-querying/5d-when-error-occurs.html.md.erb b/geode-docs/nativeclient/continuous-querying/5d-when-error-occurs.html.md.erb
deleted file mode 100644
index 25cd1fd..0000000
--- a/geode-docs/nativeclient/continuous-querying/5d-when-error-occurs.html.md.erb
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title:  When an Error Occurs in a Running CQ
----
-
-When an error occurs in CQ execution on the server, specific information on the error itself is stored in the server's log file. An exception is passed to the client, and the client throws an exception.
-
-The server log will contain an error message indicating an error while processing CQ , like this:
-
-``` pre
-[error 2007/12/18 12:03:18.903 PST <RMI TCP Connection(2)-
-192.0.2.0> tid=0x18] Error while processing CQ on the event, key :
-key-1, CqName :testCQEvents_0, ClientId :
-identity(carlos(3249):52623/35391,connection=1,durableAttributes=null)
-Error :No public attribute named 'ID' was found in class java.lang.Object
-```
-
-Errors in CQ execution are usually caused by data errors, such as invalid object types that are stored in the server region. In this case, the query is trying to read into an object of type Portfolio for an entry where an empty object has been stored. You can avoid these types of errors by placing constraints on the region entries, or by otherwise controlling the types of objects stored in your server regions.

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/continuous-querying/5e-running-cq-code.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/continuous-querying/5e-running-cq-code.html.md.erb b/geode-docs/nativeclient/continuous-querying/5e-running-cq-code.html.md.erb
deleted file mode 100644
index b5626d8..0000000
--- a/geode-docs/nativeclient/continuous-querying/5e-running-cq-code.html.md.erb
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title:  Running the Continuous Query Code
----
-
-Create your CQ from an instance of the QueryService. Once created, the CQ is maintained primarily through the CqQuery interface. The following two C++ and C\# examples show the basic calls in the CQ life cycle.
-
-## CQ Creation, Execution, and Close (C++)
-
-``` pre
-// Get cache and qrySvcPtr - refs to local cache and QueryService
-// Create client /tradeOrder region configured to talk to the server
-// Create CqAttribute using CqAttributeFactory
-CqAttributesFactory cqf;
-// Create a listener and add it to the CQ attributes
-// callback defined below
-CqListenerPtr tradeEventListener (new TradeEventListener());
-QueryServicePtr qrySvcPtr = cachePtr->getQueryService();" cqf.addCqListener(tradeEventListener);
-CqAttributesPtr cqa = cqf.create();
-// Name of the CQ and its query
-char* cqName = "priceTracker";
-char* queryStr = "SELECT * FROM /tradeOrder t where t.price > 100.00";
-// Create the CqQuery
-CqQueryPtr priceTracker = qrySvcPtr->newCq(cqName, queryStr, cqa); try {
-  // Execute CQ
-  priceTracker->execute();
-} catch (Exception& ex){
-  ex.printStackTrace();
-}
-  // Now the CQ is running on the server, sending CqEvents to the listener
-  . . .
-}
-// End of life for the CQ - clear up resources by closing
-priceTracker->close()
-```
-
-## CQ Creation, Execution, and Close (C\# .NET)
-
-``` pre
-// Get cache and queryService - refs to local cache and QueryService
-// Create client /tradeOrder region configured to talk to the server
-// Create CqAttribute using CqAttributeFactory
-CqAttributesFactory cqf = new CqAttributesFactory();
-// Create a listener and add it to the CQ attributes
-//callback defined below
-ICqListener tradeEventListener = new TradeEventListener();
-cqf.addCqListener(tradeEventListener);
-CqAttributes cqa = cqf.create();
-// Name of the CQ and its query
-String cqName = "priceTracker ";
-String queryStr = "SELECT * FROM /tradeOrder t where t.price >100.00 ";
-QueryService queryService = cache.GetQueryService();
-// Create the CqQuery
-CqQuery priceTracker = queryService.newCq(cqName, queryStr, cqa, true);
-try {
-  // Execute CQ
-  priceTracker.execute();
-  }catch (Exception ex){
-  //handle exception
-  }
-// Now the CQ is running on the server, sending CqEvents to the listener
-// . . .
-}
-// End of life for the CQ - clear up resources by closing
-priceTracker.close();
-```
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/continuous-querying/5f-cq-execution-options.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/continuous-querying/5f-cq-execution-options.html.md.erb b/geode-docs/nativeclient/continuous-querying/5f-cq-execution-options.html.md.erb
deleted file mode 100644
index 4a6c5fc..0000000
--- a/geode-docs/nativeclient/continuous-querying/5f-cq-execution-options.html.md.erb
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title:  CQ Execution Options
----
-
-CQ execution can be done with or without an initial result set by calling `CqQuery.Execute` or `CqQuery.ExecuteWithInitialResults`. The initial `SelectResults` returned from `ExecuteWithInitialResults` is the same as the one you would get if you ran the query ad hoc by calling `QueryService.NewQuery.Execute` on the server cache, but with the key added.
-
-Individual CQs are executed using` CqQueryexecute*` methods. You can also execute all CQs for the client or for a region through the client `QueryService`. CQs that are running can be stopped or closed.
-
-If you are managing a data set from the CQ results, you can initialize the set by iterating over the result set and then updating it from your listeners as events arrive. For example, you might populate a new screen with initial results and then update the screen from a listener.
-
-Just as with the standalone query, the initial results represents a possibly moving snapshot of the cache. If there are updates to the server region while the result set is being created, the result set and the subsequent event-by-event CQ query execution might miss some events.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/continuous-querying/6-managing-cqs.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/continuous-querying/6-managing-cqs.html.md.erb b/geode-docs/nativeclient/continuous-querying/6-managing-cqs.html.md.erb
deleted file mode 100644
index 0159125..0000000
--- a/geode-docs/nativeclient/continuous-querying/6-managing-cqs.html.md.erb
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title:  Managing Continuous Queries
----
-
-This section discusses how to access and manage your CQs from your client. The calls discussed here are all executed specifically for the calling client. A client cannot access or modify the CQs belonging to another client.
-
-This section discusses how to access and manage your CQs from your client. The calls discussed here are all executed specifically for the calling client. A client cannot access or modify the CQs belonging to another client.
-
-For detailed method usage, see the online API documentation.
-
-## <a id="security__section_939E26544C6E4C419336B7B04D1DE77F" class="no-quick-link"></a>Accessing CQs and CQ Statistics
-
-You can use the `QueryServicegetCq*` methods to access a single named CQ, an array of all CQs registered, and an array of all CQs registered in the client. You canuse the `CqEvent.getCq` method to access the CQ used to produce a `CqEvent`.
-
-CQ runtime statistics are available for the client through the `CqServiceStatistics` and `CqStatistics` interfaces described under [CQ API and Main Features](3-native-client-cq-api.html#security). You can get information on the events generated by a specific CQ from the `CqStatistics` object returned by `CqQuery.GetStatistics`. You can get higher-level information about the CQs the client has registered, running, and so on, from the `CqServiceStatistics` object returned by `QueryService.GetCqStatistics` .
-
-Client statistics are for the single client only. The server's pertain to all clients with CQs on this server.
-
-## <a id="security__section_0803146FEC9F4E088C01C521ED83723D" class="no-quick-link"></a>Modifying CQ Attributes
-
-You can modify the attributes for an existing CQ using the methods provided by `CqQuery.GetCqAttributesMutator`. The attributes consist of a list of listeners.
-
-## <a id="security__section_132104D528A7457A90EAE120B9080565" class="no-quick-link"></a>Stopping and Closing CQs
-
-You stop individual CQs with the `CqQuerystop` method. You can stop all CQs for the client through the `QueryService`. Stopped CQs are in the same state as new CQs that have not yet been executed. You can close or execute a stopped CQ.
-
-You close individual CQs with the `CqQueryclose` method. You can also close all CQs for the client through the `QueryService`. Closed CQs cannot be executed. CQs are also closed in the following cases:
-
--   The client closes its cache after closing all of its CQs--Closing the client cache closes the `QueryService` and all associated CQs on the client and server.
--   The client disconnects from its server--This might be because of a network outage or some other failure. When a client disconnects, all CQs created by the client are removed from the server and put into a `CLOSED` state on the client.
--   The server region is destroyed--When a server region is destroyed, all associated CQs are also cleaned up on the server and the region destroy event is sent to the client. On the client, the `CqListener.Close` method is called for all CQs on the region.
-
-## <a id="security__section_C11FA08192934D578C4FC1EFB610F50B" class="no-quick-link"></a>Getting All Durable CQs Registered with the Server
-
-To obtain a list of all durable CQs registered on the server, use the `QueryService.getAllDurableCqsFromServer` API.

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/continuous-querying/continuous-querying.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/continuous-querying/continuous-querying.html.md.erb b/geode-docs/nativeclient/continuous-querying/continuous-querying.html.md.erb
deleted file mode 100644
index db5df3d..0000000
--- a/geode-docs/nativeclient/continuous-querying/continuous-querying.html.md.erb
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title:  Continuous Querying
----
-
-*Continuous Querying* describes how to implement continuous querying in the Apache Geode native client so that C++ and .NET clients can run queries against events in the Geode cache server region. It also describes main features and the native client CQ API.
-
--   **[How Continuous Querying Works](../../nativeclient/continuous-querying/1-how-cont-query-works.html)**
-
-    C++ and .NET clients register interest in events using simple query expressions. Events are sent to client listeners that you can program to do whatever your application requires.
-
--   **[Implementing a Continuous Query](../../nativeclient/continuous-querying/5-implementing-cq.html)**
-
-    You can specify CQs for any client region.
-
--   **[Managing Continuous Queries](../../nativeclient/continuous-querying/6-managing-cqs.html)**
-
-    This section discusses how to access and manage your CQs from your client. The calls discussed here are all executed specifically for the calling client. A client cannot access or modify the CQs belonging to another client.
-
--   **[CQ API and Main Features](../../nativeclient/continuous-querying/3-native-client-cq-api.html)**
-
-    This chapter documents the primary native client API for CQ management.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/cpp-caching-api/accessing-entry.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/cpp-caching-api/accessing-entry.html.md.erb b/geode-docs/nativeclient/cpp-caching-api/accessing-entry.html.md.erb
deleted file mode 100644
index 4a97d6f..0000000
--- a/geode-docs/nativeclient/cpp-caching-api/accessing-entry.html.md.erb
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title:  Accessing an Entry
----
-
-The standard `Region::get API` method returns the value associated with the specified key, and passes the callback argument to any cache loaders or cache writers that are invoked in the operation.
-
-If the value is not present locally, it is requested from the cache server. If the cache server request is unsuccessful, a local cache loader is invoked.
-
-The entry value is either retrieved from the local cache or fetched by the region’s locally defined cache loader.
-
-In the following example, the program uses the API to do a get for each entry that was put into the cache:
-
-``` pre
-for ( int32_t i=0; i< 100; i++) {
-    CacheableInt32Ptr res = dynCast<CacheableInt32Ptr>(regionPtr->get(i));
-}
-```
-
-## <a id="concept_2B85EC4AB9FA446998147A1539D818CC__section_80F9A9E8F8514A9FBA19106C2473B370" class="no-quick-link"></a>Bulk Get Operations Using getAll
-
-You can use the `Region::getAll` API (`Region.GetAll` for .NET) to get values for an array of keys from the local cache or server. If the value for a key is not present locally, then it is requested from the server.
-
-**Note:**
-The value returned is not copied, so multi-threaded applications should not modify the value directly, but should instead use the update methods.
-
-The getAll API also supports providing a callback argument to any cache loaders or cache writers that are invoked in the operation. See the Region API documentation for more information about using `getAll`.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/cpp-caching-api/add-entry-to-cache.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/cpp-caching-api/add-entry-to-cache.html.md.erb b/geode-docs/nativeclient/cpp-caching-api/add-entry-to-cache.html.md.erb
deleted file mode 100644
index e54306a..0000000
--- a/geode-docs/nativeclient/cpp-caching-api/add-entry-to-cache.html.md.erb
+++ /dev/null
@@ -1,43 +0,0 @@
----
-title:  Adding an Entry to the Cache
----
-
-You can populate a native client region with cache entries using the `Region::put` or the `Region::create` API functions. Code examples demonstrate these actions.
-
-The `put` function places a new value into a region entry with the specified key, while the `create` function creates a new entry in the region. Both functions provide a user-defined parameter object to any cache writer invoked in the process, and new values for both functions are propagated to a connected cache server.
-
-## Adding Entries Using create
-
-When the put function adds an entry, the previous value is overwritten if there is already an entry associated with the specified key in the region. In the next example, the program uses the API to put 100 entries into the cache by iteratively creating keys and values, both of which are integers.
-
-``` pre
-for ( int32_t i=0; i < 100; i++ ) {
-    regionPtr->put( i, CacheableInt32::create(i) );
-}
-```
-
-## <a id="concept_26D4E6C6BC6F4AB8884E33119999656D__section_748916759F0246619CD27E7456DCA365" class="no-quick-link"></a>Bulk Put Operations Using putAll
-
-You can batch up multiple key/value pairs into a hashmap and put them into the cache with a single operation using the `Region::putAll` API function (`Region.PutAll` for .NET) . Each entry is processed for interest registration on the server, so each entry requires its own unique event ID. Updates and creates can be mixed in a `putAll` operation, so those events need to be addressed on the cache server for appropriate cache listener invocation on distributed system members. Map entries retain their original order when they are processed at the server.
-
-The following table lists the client and cache server statistics for `putAll`.
-
-<a id="concept_26D4E6C6BC6F4AB8884E33119999656D__table_4693B08B5B4D44118DC399C8826C9750"></a>
-
-| Statistic Type     | Chart Name                | Description                                                                                                                                     |
-|--------------------|---------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------|
-| `CachePerfStats`   | `Putalls`                 | Total number of times a map is added or replaced in the cache as a result of a local operation. Also reports the number of `putAll` operations. |
-| `CachePerfStats`   | `putallTime`              | Total time to replace a map in the cache as a result of a local operation.                                                                      |
-| `CacheServerStats` | `putAllRequests`          | Number of `putAll` requests.                                                                                                                    |
-| `CacheServerStats` | `putAllResponses`         | Number of `putAll` responses written to the cache client.                                                                                       |
-| `CacheServerStats` | `processPutAllTime`       | Total time to process a cache client `putAll` request, including the time to put all objects into the cache.                                    |
-| `CacheServerStats` | `readPutAllRequestTime`   | Total time to read `putAll` requests.                                                                                                           |
-| `CacheServerStats` | `writePutAllResponseTime` | Total time to write `putAll` responses.                                                                                                         |
-| `CacheClientStats` | `putAll`                  | Number of `putAll` requests sent to the cache server.                                                                                           |
-| `CacheClientStats` | `sendPutAllTime`          | Total time for `sendPutAll` .                                                                                                                   |
-
-<span class="tablecap">**Table 1.** putAll Statistics for Cache Server and Client</span>
-
-The putAll API also supports providing a callback argument to any cache loaders or cache writers that are invoked in the operation.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/cpp-caching-api/cpp-caching-api.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/cpp-caching-api/cpp-caching-api.html.md.erb b/geode-docs/nativeclient/cpp-caching-api/cpp-caching-api.html.md.erb
deleted file mode 100644
index fdaa372..0000000
--- a/geode-docs/nativeclient/cpp-caching-api/cpp-caching-api.html.md.erb
+++ /dev/null
@@ -1,51 +0,0 @@
----
-title:  Working with the C++ API
----
-
-This section describes the primary classes and usage conventions for the native client C++ API. It demonstrates how to use the API to create caches and perform data serialization.
-
-The online C++ API documentation is included in the `docs/cppdocs` directory of the native client product installation. It provides extensive implementation details for the C++ structures and functions.
-
-Several example API programs are included in the `SampleCode` directory. See [QuickStart Examples and Guide](../introduction/examples-quickstart.html#examples-quickstart).
-
--   **[About the Native Client C++ API](../../nativeclient/cpp-caching-api/gfe-cpp-api.html)**
-
-    The native client C++ API allows C++ and .NET developers to programmatically create, populate, and manage a Geode distributed system. The C++ library is thread-safe, except where specified otherwise in the online API documentation.
-
--   **[Creating a Cache](../../nativeclient/cpp-caching-api/creating-cache.html)**
-
-    The code snippets in this section show cache creation.
-
--   **[Creating a Proxy Client-Side Region](../../nativeclient/cpp-caching-api/creating-region.html)**
-
-    This section provides code examples for creating and customizing proxy client-side regions.
-
--   **[Adding an Entry to the Cache](../../nativeclient/cpp-caching-api/add-entry-to-cache.html)**
-
-    You can populate a native client region with cache entries using the `Region::put` or the `Region::create` API functions. Code examples demonstrate these actions.
-
--   **[Accessing an Entry](../../nativeclient/cpp-caching-api/accessing-entry.html)**
-
-    The standard `Region::get API` method returns the value associated with the specified key, and passes the callback argument to any cache loaders or cache writers that are invoked in the operation.
-
--   **[Removing an Entry](../../nativeclient/cpp-caching-api/removing-entry.html)**
-
-    The standard `Region::remove` API removes the entry with the specified key and provides a user-defined parameter object to any `CacheWriter` or `CacheListener` invoked in the process.
-
--   **[Serializing Data](../../nativeclient/cpp-caching-api/serialization_overview.html)**
-
-    All data that Geode moves out of the local cache must be serializable.
-
--   **[Implementing User-Defined Objects in Java Clients](../../nativeclient/cpp-caching-api/user-defined-objects.html)**
-
-    You can use one of two methods to implement a user-defined object in a Java client that works with C++ clients: `Instantiator.register` and `DataSerializable`.
-
--   **[Using a Custom Class](../../nativeclient/cpp-caching-api/using-custom-class.html)**
-
-    This example shows how to use the defined `BankAccount` custom key type and the `AccountHistory` value type.
-
--   **[Creating New Statistics](../../nativeclient/cpp-caching-api/creating-new-statistics.html)**
-
-    This example provides a programmatic code sample for creating and registering new statistics.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/cpp-caching-api/creating-cache.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/cpp-caching-api/creating-cache.html.md.erb b/geode-docs/nativeclient/cpp-caching-api/creating-cache.html.md.erb
deleted file mode 100644
index 59b8979..0000000
--- a/geode-docs/nativeclient/cpp-caching-api/creating-cache.html.md.erb
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title:  Creating a Cache
----
-
-The code snippets in this section show cache creation.
-
-When you create your cache, the system automatically connects your process to the server tier. For systems with security enabled, the credentials for a connecting client are authenticated when it creates the cache. See [Security](../security/overviewsecurity.html#security) for more information about authenticated connections.
-
-## Creating the System Connection and the Cache
-
-In this example, the application creates the cache by calling the `CacheFactory::create` function, specifying the servers to connect to:
-
-``` pre
-CacheFactoryPtr cacheFactory = CacheFactory::createCacheFactory();
-    CachePtr cachePtr = cacheFactory  
-                        ->addServer("localhost", 40404)
-                        ->addServer("localhost", 40405)
-                        ->setSubscriptionEnabled(true)
-                        ->create();
-```
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/cpp-caching-api/creating-new-statistics.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/cpp-caching-api/creating-new-statistics.html.md.erb b/geode-docs/nativeclient/cpp-caching-api/creating-new-statistics.html.md.erb
deleted file mode 100644
index 9a30dca..0000000
--- a/geode-docs/nativeclient/cpp-caching-api/creating-new-statistics.html.md.erb
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title:  Creating New Statistics
----
-
-This example provides a programmatic code sample for creating and registering new statistics.
-
-For information about the `gemfire_statistics` API, see [Statistics API](gfe-cpp-api.html#concept_AB12290E89CA4724AC9F51EFF7B8B8EA__section_42764C6327944514AE4A26684D7EBCB0).
-
-## Creating New Statistics Programmatically
-
-``` pre
-//Get StatisticsFactory 
-StatisticsFactory* factory = StatisticsFactory::getExistingInstance(); 
- 
- 
-//Define each StatisticDescriptor and put each in an array 
-StatisticDescriptor** statDescriptorArr = new StatisticDescriptor*[6]; 
-statDescriptorArr[0] = statFactory->createIntCounter("IntCounter",
-    "Test Statistic Descriptor Int Counter.","TestUnit"); 
- 
-statDescriptorArr[1] = statFactory->createIntGauge("IntGauge",
-    "Test Statistic Descriptor Int Gauge.","TestUnit");
- 
-statDescriptorArr[2] = statFactory->createLongCounter("LongCounter",
-    "Test Statistic Descriptor Long Counter.","TestUnit");
- 
-statDescriptorArr[3] = statFactory->createLongGauge("LongGauge",
-    "Test Statistic Descriptor Long Gauge.","TestUnit");
- 
-statDescriptorArr[4] = statFactory->createDoubleCounter("DoubleCounter",
-    "Test Statistic Descriptor Double Counter.","TestUnit");
- 
-statDescriptorArr[5] = statFactory->createDoubleGauge("DoubleGauge",
-    "Test Statistic Descriptor Double Gauge.","TestUnit");
- 
- 
-//Create a StatisticsType 
-StatisticsType* statsType = statFactory->createType("TestStatsType", 
-    "Statistics for Unit Test.",statDescriptorArr, 6); 
- 
-//Create Statistics of a given type 
-Statistics* testStat = 
-    factory->createStatistics(statsType,"TestStatistics"); 
- 
- 
-//Statistics are created and registered. Set and increment individual values 
-Int statIdIntCounter = statsType->nameToId("IntCounter"); 
-testStat->setInt(statIdIntCounter, 10 );
-testStat->incInt(statIdIntCounter, 1 );
-int currentValue = testStat->getInt(statIdIntCounter);
-```
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/cpp-caching-api/creating-region.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/cpp-caching-api/creating-region.html.md.erb b/geode-docs/nativeclient/cpp-caching-api/creating-region.html.md.erb
deleted file mode 100644
index c6f8eb1..0000000
--- a/geode-docs/nativeclient/cpp-caching-api/creating-region.html.md.erb
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title:  Creating a Proxy Client-Side Region
----
-
-This section provides code examples for creating and customizing proxy client-side regions.
-
-**Note:**
-Creating a region through the native client API creates only a proxy client-side region. A corresponding region with the same name and path should also exist on the servers that have been configured for client connections and upon which the client will perform its operations.
-
-To create a region, you create a `RegionFactory` using the `RegionShortcut` that most closely fits your region configuration. From that, create your region, customizing the settings as region attributes as needed.
-
-## Creating a CACHING\_PROXY Region
-
-This example creates a region using a CACHING\_PROXY `RegionShortcut` with no further modifications:
-
-``` pre
-RegionFactoryPtr regionFactory = 
-            cachePtr->createRegionFactory(CACHING_PROXY);
-regionPtr = regionFactory ->create("exampleRegion");
-```
-
-## Creating a CACHING\_PROXY Region with LRU
-
-This example creates a region based on the CACHING\_PROXY RegionShortcut with two additional region attributes settings. For information on the settings, see [Region Attributes Descriptions](../client-cache/region-attributes-desc.html#region-attributes-desc).
-
-``` pre
-RegionFactoryPtr regionFactory = 
-              cachePtr->createRegionFactory(CACHING_PROXY);
-regionPtr = regionFactory->setLruEntriesLimit( 20000 )
-              ->setInitialCapacity( 20000 )
-              ->create("exampleRegion");
-```
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/cpp-caching-api/data-as-blob.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/cpp-caching-api/data-as-blob.html.md.erb b/geode-docs/nativeclient/cpp-caching-api/data-as-blob.html.md.erb
deleted file mode 100644
index 85d3209..0000000
--- a/geode-docs/nativeclient/cpp-caching-api/data-as-blob.html.md.erb
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title:  Serializing and Accessing Data as a Blob
----
-
-If you have data that is best handled as a blob, such as structs that do not contain pointers, use the serializable type `CacheableBytes` . `CacheableBytes` is a blob class that implements the serialization for you.
-
-`CacheableBytes` also provides direct access to the blob data. Because it is not derived from the `CacheableKey` interface, `CacheableBytes` enables you to modify data in place and then put it into the region again to distribute the change.
-
-For more information, see the API documentation for `CacheableBytes.`
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/cpp-caching-api/gfe-cpp-api.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/cpp-caching-api/gfe-cpp-api.html.md.erb b/geode-docs/nativeclient/cpp-caching-api/gfe-cpp-api.html.md.erb
deleted file mode 100644
index f6258fa..0000000
--- a/geode-docs/nativeclient/cpp-caching-api/gfe-cpp-api.html.md.erb
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title:  About the Native Client C++ API
----
-
-The native client C++ API allows C++ and .NET developers to programmatically create, populate, and manage a Geode distributed system. The C++ library is thread-safe, except where specified otherwise in the online API documentation.
-
-This chapter gives a general overview of the classes in the `gemfire`, `gemfire_statistics`, and `gemfire_admin` namespaces. For complete and current information on the classes listed here, see the online C++ API documentation.
-
-## <a id="concept_AB12290E89CA4724AC9F51EFF7B8B8EA__section_14B45E09CA014951AD38D0E051DF8727" class="no-quick-link"></a>Cache Classes
-
-The native client C++ API has the following cache classes:
-
--   **CacheFactory**. Use this class to create and configure a `Cache` instance. If `cache.xml` is specified, the cache is created based on the declarations loaded from that file.
--   **Cache**. Entry point to the client caching API. The cache is created by calling the `create` function of the factory class, `CacheFactory`. Regions are configured and obtained using the `Cache::createRegionFactory()` API.
-
-## <a id="concept_AB12290E89CA4724AC9F51EFF7B8B8EA__section_9F27929D85CC4EBFB29925974776C985" class="no-quick-link"></a>Region Classes
-
-The native client C++ API has the following region classes:
-
--   **Region**. Provides functions for managing regions and cached data. Use these functions to perform the following actions:
-    -   Retrieve information about the region, such as its parent region and region attribute objects.
-    -   Invalidate or destroy the region.
-    -   Create, update, invalidate and destroy region entries.
-    -   Retrieve region entry keys, entry values, and RegionEntry objects, either individually or as entire sets.
-    -   Retrieve the statistics object associated with the region.
-    -   Set and get user-defined attributes.
--   **RegionEntry**. Contains the key and value for the entry, and provides all non-distributed entry operations. This object's operations are not distributed and do not affect statistics.
-
-## <a id="concept_AB12290E89CA4724AC9F51EFF7B8B8EA__section_CEC4E57E76E84D099D0F55F49F3B64DA" class="no-quick-link"></a>Region Attribute Classes
-
-The native client C++ API has the following region attribute classes:
-
--   **RegionAttributes**. Holds all attribute values for a region and provides functions for retrieving all attribute settings. This class can be modified by the `AttributesMutator` class after region creation.
--   **AttributesMutator** . Allows modification of an existing region’s attributes for application plug-ins and expiration actions. Each region has an `AttributesMutator` instance.
-
-## <a id="concept_AB12290E89CA4724AC9F51EFF7B8B8EA__section_658D04298E13459382D48544AF36A2FA" class="no-quick-link"></a>Application Plug-In Classes
-
-The native client C++ API has the following application plug-in classes:
-
--   **CacheLoader**. Loads data into a region on a cache miss.
--   **CacheWriter**. Synchronously handles region and entry events before the events occur. Entry events are `create`, `update`, `invalidate`, and `destroy`. Region events are invalidate and destroy. This class has the ability to abort events.
--   **CacheListener**. Handles region and entry events after they occur. Entry events are `create`, `update`, `invalidate`, and `destroy`. Region events are `invalidate` and `destroy`.
-
-## <a id="concept_AB12290E89CA4724AC9F51EFF7B8B8EA__section_B3479F5739B048C0BD3EDA89BE0266E0" class="no-quick-link"></a>Event Handling Classes
-
-The native client C++ API has the following event handling classes:
-
--   **RegionEvent**. Provides information about the event, such as in what region the event originated, whether the event originated in a cache remote to the event handler, and whether the event resulted from a distributed operation.
--   **EntryEvent**. Provides all available information for the `RegionEvent`, and provides entry-specific information such as the old and new entry values and whether the event resulted from a `load` operation.
-
-## <a id="concept_AB12290E89CA4724AC9F51EFF7B8B8EA__section_42764C6327944514AE4A26684D7EBCB0" class="no-quick-link"></a>Statistics API
-
-The `StatisticsType` API represents a blueprint for the same type of `Statistics`. The `StatisticsType` API is a collection of `StatisticDescriptor`. Internally, each `StatisticDescriptor` describes data of each individual statistic. `StatisticsFactory` provides functionality for creating `StatisticDescriptor`, `StatisticsType`, and `Statistics`.
-
--   **CacheStatistics** --This class defines common statistics functions. `Region` and `RegionEntry` both have functions that return a `CacheStatistics` object for accessing and resetting their statistics counts.
--   **StatisticDescriptor**. An instance of this class describes a statistic whose value is updated by an application and may be archived by the native client. Each statistic has a type of either `int`, `long`, or `double`, and either a gauge or a counter. The value of a gauge can increase and decrease, and the value of a counter strictly increases. Create an instance of `StatisticDescriptor` by calling one of these `StatisticsFactory` functions: `createDoubleCounter`, `createDoubleGauge`, `createIntCounter`, `createIntGauge`, `createLongCounter`, `createLongGauge`.
--   **StatisticsType**. An instance of this class describes a logical collection of `StatisticDescriptors`. These descriptions are used to create an instance of `Statistics`. Create an instance of `StatisticsType` by calling `StatisticsFactory::createType`.
--   **Statistics**. An instance of this class represents concrete `Statistics` of the associated `StatisticsType`. This class stores data related to all individual statistic objects. Create an instance by calling `StatisticsFactory::createStatistics`. This class has functions to get, set, and increment statistic values.
--   **StatisticsFactory**. This class provides functions for creating instances of `StatisticDescriptor`, `StatisticsType`, and `Statistics objects`. This is a singleton class, and you acquire its instance by using `StatisticsFactory::getExistingInstance`.
-
-To create new statistics, see [Creating New Statistics](creating-new-statistics.html#concept_664156CBD79C44C4B200DA2D64180A65).

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/cpp-caching-api/object-graphs.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/cpp-caching-api/object-graphs.html.md.erb b/geode-docs/nativeclient/cpp-caching-api/object-graphs.html.md.erb
deleted file mode 100644
index 9cced86..0000000
--- a/geode-docs/nativeclient/cpp-caching-api/object-graphs.html.md.erb
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title:  Serializing Object Graphs
----
-
-If you have a graph of objects where each node can be serializable, the parent node can call `DataOutput::writeObject` to delegate the serialization responsibility to its child nodes. Similarly, your application can call `DataInput::readObject` to deserialize the object graph.
-
-For more information, see the API documentation for `DataOutput` and `DataInput`.
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/cpp-caching-api/pdx_auto_serialization.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/cpp-caching-api/pdx_auto_serialization.html.md.erb b/geode-docs/nativeclient/cpp-caching-api/pdx_auto_serialization.html.md.erb
deleted file mode 100644
index 0bdda28..0000000
--- a/geode-docs/nativeclient/cpp-caching-api/pdx_auto_serialization.html.md.erb
+++ /dev/null
@@ -1,355 +0,0 @@
----
-title: Using Automatic PDX Serialization
----
-
-You can allow your native client C++ applications to automatically PDX serialize and deserialize domain objects without having to add any extra code by using the `pdxautoserializer` command line tool provided with the native client.
-
-When using the native client C++ API, you can automatically serialize and deserialize domain objects without making any code changes to those objects or having to implement a `PdxSerializer` or `PdxSerializable` interface and their related `fromData` and `toData` methods. The Geode native client includes a command-line utility, `pdxautoserializer`, that allows you to generate C++ code that will serialize your domain objects in the PDX format for you.
-
-## <a id="task_czj_wnw_dl" class="no-quick-link"></a>How to Use Automatic PDX Serialization
-
-**Prerequisites:**
-
--   Understand generally how to configure the Geode cache.
-
--   Understand how PDX serialization works and how to configure your application to use PdxSerializer.
-
-The procedure below uses the following sample class:
-
-``` pre
-class PortfolioPdx 
-{
-  private:
-    int32_t id;
-    char* pkid;
-    PositionPdxPtr position1;
-    PositionPdxPtr position2;
-    CacheableHashMapPtr positions;
-    char** names;    
-    int8_t* newVal;
-    CacheableDatePtr creationDate;
-    int8_t* arrayNull;
-    int8_t* arrayZeroSize;
-  public:
-    // CTOR
-    // DTORS
-    // Other Methods declarations
-```
-
-For each domain class you provide, all fields are considered for serialization except those defined as static or transient and those you explicitly exclude using macros.
-
-1.  Inherit your class from `gemfire::PdxSerializable`.
-
-    ``` pre
-    class PortfolioPdx : public PdxSerializable
-    ```
-
-2.  Add the following method declarations in the public part of the class.
-
-    ``` pre
-    const char* getClassName() const;
-    virtual void toData(gemfire::PdxWriterPtr pw);
-    virtual void fromData(gemfire::PdxReaderPtr pr);
-    static PdxSerializable* createDeserializable();
-    ```
-
-3.  In your pre-build environment (for example in your **makefiles**), call `pdxautoserializer` as follows:
-
-    ``` pre
-    <GFCPP>/bin/pdxautoserializer.exe --outDir=<location to generate files> <SOURCE_DIR>/PortfolioPdx.hpp
-    ```
-
-4.  Include the generated file in your project and compile.
-
-The following is an example of a generated file:
-
-``` pre
-#include "PortfolioPdx.hpp"
-#include <gfcpp/PdxWriter.hpp>
-#include <gfcpp/PdxReader.hpp>
-#include <gfcpp/PdxAutoSerializer.hpp>
-namespace testobject
-{
-  void PortfolioPdx::toData(gemfire::PdxWriterPtr var)
-  {
-    gemfire::PdxAutoSerializable::writePdxObject(var, "id", id);
-    gemfire::PdxAutoSerializable::writePdxObject(var, "pkid", pkid);
-    gemfire::PdxAutoSerializable::writePdxObject(var, "position1", position1);
-    gemfire::PdxAutoSerializable::writePdxObject(var, "position2", position2);
-    gemfire::PdxAutoSerializable::writePdxObject(var, "positions", positions);
-    gemfire::PdxAutoSerializable::writePdxObject(var, "status", status);
-    gemfire::PdxAutoSerializable::writePdxObject(var, "creationDate", creationDate);
-  }
-
-  void PortfolioPdx::fromData(PdxReaderPtr var)
-  {
-    gemfire::PdxAutoSerializable::readPdxObject(var, "id", id);
-    gemfire::PdxAutoSerializable::readPdxObject(var, "pkid", pkid);
-    gemfire::PdxAutoSerializable::readPdxObject(var, "position1", position1);
-    gemfire::PdxAutoSerializable::readPdxObject(var, "position2", position2);
-    gemfire::PdxAutoSerializable::readPdxObject(var, "positions", positions);
-    gemfire::PdxAutoSerializable::readPdxObject(var, "status", status);
-    gemfire::PdxAutoSerializable::readPdxObject(var, "creationDate", creationDate);
-  }
-  
-  const char* PortfolioPdx::getClassName()  const
-  {
-     return "PortfolioPdx";
-  }
-}
-```
-
-## <a id="task_fs4_vkj_2l" class="no-quick-link"></a>Handling Arrays
-
-1.  Define the following macro in your header file:
-
-    ``` pre
-    #define GFARRAYSIZE(x)
-    ```
-
-2.  Assuming that the following is the class member of type array:
-
-    ``` pre
-    int8_t* newVal;
-    ```
-
-    Then define a new variable which sets the length of the array:
-
-    ``` pre
-    int32_t newValSize;
-    ```
-
-3.  Tag the new variable with the `GFARRAYSIZE` macro as follows:
-
-    ``` pre
-    GFARRAYSIZE(newVal) int32_t newValSize;
-    ```
-
-## Using a Single Variable as Length for Multiple Arrays
-
-You can use the GFARRAYSIZES to have single length for multiple arrays.
-
-Define the GFARRAYSIZES macro as follows:
-
-``` pre
-#define GFARRAYSIZES(x)
-```
-
-The following is an example usage:
-
-``` pre
-class ArrayOfSizes?
-    {
-    public:
-    int32_t* array1;
-    int32_t* array2;
-    int32_t* array3;
-    int32_t* array4;
-    int32_t* array5;
-
-    GFARRAYSIZE(array1) int32_t singleSize; 
-    GFARRAYSIZES("array2,array3,array4,array5") int32_t SingleSizeToMultipleArrays?;
-  };​
-```
-
-## <a id="task_hph_mrw_dl" class="no-quick-link"></a>Excluding Member Variables from Serialization
-
-1.  Define the following macro in your header file:
-
-    ``` pre
-    #define GFEXCLUDE
-    ```
-
-2.  Tag your member variable with this macro:
-
-    ``` pre
-    GFEXCLUDE char* type;
-    ```
-
-## <a id="task_en2_4rw_dl" class="no-quick-link"></a>Marking Identity Fields
-
-Identity fields are used when comparing objects using the `hashCode` and `equals` methods.
-
-1.  Define the following macro in your header file.
-
-    ``` pre
-    #define GFID(x)
-    ```
-
-2.  Assuming that the following is the class member you want to use as IdentityField:
-
-    ``` pre
-    int8_t* newVal;
-    ```
-
-    Tag the member with the GFID macro as follows:
-
-    ``` pre
-    GFID(newVal)int8_t* newVal;
-    ```
-
-## Ignoring User Defined Keywords
-
-You might have certain user defined keywords after the class name. Current C++ grammar does not support this. If you have some keywords user will have to ignore them by using the `GFIGNORE` macro.
-
-For example, consider the following class definition:
-
-``` pre
-#ifdef _WIN32
-#ifdef BUILD_TESTOBJECT
-#define TESTOBJECT_EXPORT LIBEXP
-#else
-#define TESTOBJECT_EXPORT LIBIMP
-#endif
-#else
-#define TESTOBJECT_EXPORT
-#endif
-
-namespace PdxAutoTests {
-  class TESTOBJECT_EXPORT PdxAutoMegaType :  public PdxSerializable {
-  }
-```
-
-Currently, the `pdxautoserializer` tool will fail to recognize `TESTOBJECT_EXPORT`. Change your class by adding the `GFIGNORE` macro as follows:
-
-``` pre
-#ifdef _WIN32
-#ifdef BUILD_TESTOBJECT
-#define TESTOBJECT_EXPORT LIBEXP
-#else
-#define TESTOBJECT_EXPORT LIBIMP
-#endif
-#else
-#define TESTOBJECT_EXPORT
-#endif
-
-using namespace gemfire;
-
-#define GFIGNORE(X) X
-#define GFID
-
-namespace PdxAutoTests {
-  class GFIGNORE(TESTOBJECT_EXPORT) PdxAutoMegaType :  public PdxSerializable {
-```
-
-## <a id="topic_d3q_v3c_2l" class="no-quick-link"></a>Additional Usage Information for the pdxautoserializer Tool
-
-The `pdxautoserializer` tool takes classes as input and generates code that will serialize the class into the PDX format for you.
-
-The `pdxautoserializer` tool is located in `$GFCPP/bin` where `$GFCPP` corresponds to the installation location of the native client.
-
-Some additional notes about using the `pdxautoserializer` tool:
-
--   Any const type in the class members are ignored by the `pdxserializer` tool.
--   Generated files will have namespace in the file name.
-
-To view the command-line help for the tool, type:
-
-``` pre
-prompt> pdxautoserializer.exe --help
-```
-
-Help returns the following syntax and usage information:
-
-``` pre
-Usage: pdxautoserializer.exe [OPTIONS] <resources e.g. header> ...
-
-Resource name should be the path to the header containing the classes to be 
-auto-serialized.
-
-[OPTIONS] may be one of those given below.
-
-SINGLE denotes that the option should be specified only once.
-MULTIPLE denotes that the option can be specified more than once.
-OPTIONAL denotes that the option may be skipped in which case the default 
-for that shall be chosen.
-
---className=VALUE       Name of the class for which to generate auto-serialization code (MULTIPLE,OPTIONAL)
---classNameStr=VALUE    Name of the class in string (MULTIPLE,OPTIONAL)
---help                  This help message.
---outDir                The output directory of the generated files (SINGLE,OPTIONAL)
---suffix                The suffix of the generated filenames -- default is 'Serializable' (SINGLE,OPTIONAL)
---usage                 This usage message.
-
-Examples:
-pdxautoserializer -outDir=<DIR NAME> <RESOURCE>
-pdxautoserializer -outDir=<DIR NAME> --className=<CLASSNAME1> --className=<CLASSNAME2> <RESOURCE>
-pdxautoserializer -outDir=<DIR NAME> --classNameStr=<CLASSNAME1:User defined String> --classNameStr=<CLASSNAME:User defined String> <RESOURCE>
-
-Helper Macros to be defined in Input Header File :
-GFINCLUDE        for including a specific member for serialization
-GFEXCLUDE        for excluding a specific member for serialization
-GFID             for considering a member as Identify Field
-GFARRAYSIZE      for specifying a array length member
-GFIGNORE         for ignoring certain keywords
-For more details refer to documentation on this utility.
-```
-
-## Generating Automatic Code for a Single Class
-
-Many times there are multiple classes in a single header file. For example:
-
-``` pre
-#ifndef HEADER_HEADER
-#define HEADER_HEADER
-
-class class1{
-};
-class class2{
-};
-class class3 : public PdxSerializable{
-};
-#endif
-```
-
-If you want to generate code for only one of the classes, then use the `--className` option. For example, if you only want to generate code for class3, then you would use the following command:
-
-``` pre
-pdxautoserializer --outDir=<outDir> --className=class3
-```
-
-## Choosing Your Own Suffix to Identify the Generated Files.
-
-The `pdxserializer` tool also provides the option to choose your own suffix for the generated C++ files. This can help you write less code in your makefiles. Here's an example command:
-
-``` pre
-pdxautoserializer --outDir=<outDir> --className=CharTypes --suffix="generated"
-```
-
-## <a id="topic_f33_fsw_dl" class="no-quick-link"></a>Example of Using PDX Serialization in Your Application
-
-``` pre
-CacheFactoryPtr cacheFactory = CacheFactory::createCacheFactory();
-    // Create a GemFire Cache with the "clientPdxRemoteQuery.xml" Cache XML file.
-    CachePtr cachePtr = cacheFactory->set("cache-xml-file", "XMLs\\clientPdxRemoteQuery.xml")
-                        ->create();
-
-    LOGINFO("Created the Cache");
-
-    // Get the example Region from the Cache which is declared in the Cache XML file.
-    RegionPtr regionPtr = cachePtr->getRegion( "Portfolios");
-
-    LOGINFO( "Obtained the Region from the Cache");
-
-    // Register our Serializable/Cacheable Query objects, viz. PortfolioPdx and PositionPdx.
-    Serializable::registerPdxType(PortfolioPdx::createDeserializable);
-    PortfolioPdxPtr port1Ptr(new PortfolioPdx(1 /*ID*/, 10 /*size*/));
-    PortfolioPdxPtr port2Ptr(new PortfolioPdx(2 /*ID*/, 20 /*size*/));
-    PortfolioPdxPtr port3Ptr(new PortfolioPdx(3 /*ID*/, 30 /*size*/));
-    regionPtr->put("Key1", port1Ptr);
-    regionPtr->put("Key2", port2Ptr);
-    regionPtr->put("Key3", port3Ptr);
-    
-    // Get the QueryService from the Cache.
-    QueryServicePtr qrySvcPtr = cachePtr->getQueryService( "examplePool");
-
-    LOGINFO( "Got the QueryService from the Cache");
-
-    // Execute a Query which returns a ResultSet.
-    QueryPtr qryPtr = qrySvcPtr->newQuery("SELECT DISTINCT * FROM /Portfolios");
-    SelectResultsPtr resultsPtr = qryPtr->execute();
-
-    LOGINFO( "ResultSet Query returned %d rows", resultsPtr->size());
-```
-
-

http://git-wip-us.apache.org/repos/asf/geode-native/blob/de0559be/geode-docs/nativeclient/cpp-caching-api/pdx_ignore_unread_fields.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/nativeclient/cpp-caching-api/pdx_ignore_unread_fields.html.md.erb b/geode-docs/nativeclient/cpp-caching-api/pdx_ignore_unread_fields.html.md.erb
deleted file mode 100644
index 07093d1..0000000
--- a/geode-docs/nativeclient/cpp-caching-api/pdx_ignore_unread_fields.html.md.erb
+++ /dev/null
@@ -1,20 +0,0 @@
----
-title:  Configuring PDX to Ignore Unread Fields During Deserialization
----
-
-Use the `setPdxIgnoreUnreadFields` API to control whether PDX ignores fields that were unread during deserialization.
-
-The default is to preserve unread fields by including their data during serialization. However, if you configure the cache to ignore unread fields then their data will be lost during serialization.
-
-You should only set this attribute to `true` if you know this member will only be reading cache data. In this use case you do not need to pay the cost of preserving unread fields since you will never reserialize the PDX data.
-
-For example:
-
-``` pre
-CacheFactoryPtr cfPtr = CacheFactory::createCacheFactory(PropertiesObj);
-cfPtr->setPdxReadSerialized(tue);
-cfPtr->setPdxIgnoreUnreadFields(false);
-cachePtr = cfPtr->create();
-```
-
-


Mime
View raw message