http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/connection-pools/configuring-pools-attributes-example.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/connection-pools/configuring-pools-attributes-example.html.md.erb b/geode-docs/nativeclient/connection-pools/configuring-pools-attributes-example.html.md.erb deleted file mode 100644 index 62e033b..0000000 --- a/geode-docs/nativeclient/connection-pools/configuring-pools-attributes-example.html.md.erb +++ /dev/null @@ -1,156 +0,0 @@ ---- -title: Pool Configuration Example and Settings ---- - -Connection pools require standard client/server distributed system and cache configuration settings. You must also configure settings for the locator, server, and pool elements. - -- Locator. Host and port where a server locator is listening. -- Server. Host and port where a server is listening. -- Pool. Client/server connection pool. - -The example shows a declarative pool configuration. Following the example is a table that describes the attributes that can be configured. - -## ExampleâDeclarative Pool Configuration - -This example shows a declarative pool configuration. - -**Note:** -You create an instance of `PoolFactory` through `PoolManager`. - -``` pre -<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="true"> - <locator host="localhost" port="34756"/> -</pool> -``` - -## <a id="configuring-pools__section_E7AA69F3BB6C4FEA8094E2BC5278A349" class="no-quick-link"></a>Pool Attributes - -<table> -<colgroup> -<col width="25%" /> -<col width="50%" /> -<col width="25%" /> -</colgroup> -<thead> -<tr class="header"> -<th>Attribute Name</th> -<th>Description</th> -<th>Default</th> -</tr> -</thead> -<tbody> -<tr class="odd"> -<td><code class="ph codeph">free-connection-timeout</code></td> -<td><p>Number of milliseconds (ms) that the client waits for a free connection if <code class="ph codeph"> max-connections</code> limit is configured and all connections are in use.</p></td> -<td><p>10000 ms</p></td> -</tr> -<tr class="even"> -<td><p><code class="ph codeph">idle-timeout</code></p></td> -<td><p>Number of milliseconds to wait for a connection to become idle for load balancing</p></td> -<td><p>5000 ms</p></td> -</tr> -<tr class="odd"> -<td><code class="ph codeph">load-conditioning-interval</code></td> -<td><p>Interval in which the pool checks to see if a connection to a specific server should be moved to a different server to improve the load balance.</p></td> -<td><p>300000 ms (5 minutes)</p></td> -</tr> -<tr class="even"> -<td><code class="ph codeph">max-connections</code></td> -<td><p>Maximum number of connections that the pool can create. If all connections are in use, an operation requiring a client-to server-connection is blocked until a connection is available or the <code class="ph codeph"> free-connection-timeout</code> is reached. If set to -1, there is no maximum. The setting must indicate a cap greater than <code class="ph codeph"> min-connections</code>.</p> -<div class="note note"> -**Note:** -<p>If you use this setting to cap your pool connections, disable the pool attribute <code class="ph codeph"> pr-single-hop-enabled</code>. Leaving single hop enabled can increase thrashing and lower performance.</p> -</div></td> -<td><p>-1</p></td> -</tr> -<tr class="odd"> -<td><p><code class="ph codeph">min-connections</code></p></td> -<td><p>Number of connections that must be created initially.</p></td> -<td><p>5</p></td> -</tr> -<tr class="even"> -<td><p><code class="ph codeph">name</code></p></td> -<td><p>Pool name.</p></td> -<td><p></p></td> -</tr> -<tr class="odd"> -<td><p><code class="ph codeph">ping-interval</code></p></td> -<td><p>Interval between pinging the server to show the client is alive, set in milliseconds. Pings are only sent when the <code class="ph codeph">ping-interval</code> elapses between normal client messages. This must be set lower than the serverâs <code class="ph codeph">maximum-time-between-pings</code>.</p></td> -<td><p>10000 ms</p></td> -</tr> -<tr class="even"> -<td><p><code class="ph codeph">pr-single-hop-enabled</code></p></td> -<td><p>Setting used for single-hop access to partitioned region data in the servers for some data operations. See <a href="../client-cache/application-plugins.html#application-plugins__section_348E00A84F274D4B9DBA9ECFEB2F012E">PartitionResolver</a>. See note in <code class="ph codeph">thread-local-connections</code> below.</p></td> -<td><p>True</p></td> -</tr> -<tr class="odd"> -<td><p><code class="ph codeph">read-timeout</code></p></td> -<td><p>Number of milliseconds to wait for a response from a server before the connection times out.</p></td> -<td><p>10000</p></td> -</tr> -<tr class="even"> -<td><p><code class="ph codeph">retry-attempts</code></p></td> -<td><p>Number of times to retry an operation after a time-out or exception for high availability. If set to -1, the pool tries every available server once until it succeeds or has tried all servers.</p></td> -<td><p>-1</p></td> -</tr> -<tr class="odd"> -<td><p><code class="ph codeph">server-group</code></p></td> -<td><p>Server group from which to select connections. If not specified, the global group of all connected servers is used.</p></td> -<td><p>empty</p></td> -</tr> -<tr class="even"> -<td><p><code class="ph codeph">socket-buffer-size</code></p></td> -<td><p>Size of the socket buffer, in bytes, on each connection established.</p></td> -<td><p>32768</p></td> -</tr> -<tr class="odd"> -<td><p><code class="ph codeph">statistic-interval</code></p></td> -<td><p>Default frequency, in milliseconds, with which the client statistics are sent to the server. A value of <code class="ph codeph">-1</code> indicates that the statistics are not sent to the server.</p></td> -<td><p>-1</p></td> -</tr> -<tr class="even"> -<td><p><code class="ph codeph">subscription-ack-interval</code></p></td> -<td><p>Number of milliseconds to wait before sending an acknowledgment to the server about events received from the subscriptions.</p></td> -<td><p>100</p></td> -</tr> -<tr class="odd"> -<td><p><code class="ph codeph">subscription-enabled</code></p></td> -<td><p>Whether to establish a server to client subscription.</p></td> -<td><p>False</p></td> -</tr> -<tr class="even"> -<td><p><code class="ph codeph">subscription-message-tracking-timeout</code></p></td> -<td><p>Number of milliseconds for which messages sent from a server to a client are tracked. The tracking is done to minimize duplicate events.</p></td> -<td><p>90000</p></td> -</tr> -<tr class="odd"> -<td><p><code class="ph codeph">subscription-redundancy</code></p></td> -<td><p>Redundancy for servers that contain subscriptions established by the client. A value of <code class="ph codeph">-1</code> causes all available servers in the specified group to be made redundant.</p></td> -<td><p>0</p></td> -</tr> -<tr class="even"> -<td><p><code class="ph codeph">thread-local-connections</code></p></td> -<td><p>Whether the connections must have affinity to the thread that last used them.</p> -<div class="note note"> -**Note:** -<p>To set this to <code class="ph codeph">true</code>, also set <code class="ph codeph">pr-single-hop-enabled</code> to <code class="ph codeph">false</code>. A <code class="ph codeph">true</code> value in <code class="ph codeph">pr-single-hop-enabled</code> automatically assigns a <code class="ph codeph">false</code> value to <code class="ph codeph">thread-local-connections</code>...</p> -</div></td> -<td><p>False</p></td> -</tr> -<tr class="odd"> -<td><code class="ph codeph">update-locator-list-interval</code></td> -<td>An integer number of milliseconds defining the interval between locator list updates. If the value is less than or equal to 0, the update will be disabled.</td> -<td>5000</td> -</tr> -</tbody> -</table> - -
http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/connection-pools/configuring-pools.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/connection-pools/configuring-pools.html.md.erb b/geode-docs/nativeclient/connection-pools/configuring-pools.html.md.erb deleted file mode 100644 index 3b04643..0000000 --- a/geode-docs/nativeclient/connection-pools/configuring-pools.html.md.erb +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Configuring Pools ---- - -A pool can be configured as locators or as a list of servers. - -You configure locator, server, and pool settings declaratively in the client's `cache.xml` file or programmatically through the `PoolFactory` method. You create an instance of `PoolFactory` through `PoolManager`. - -- **[Native Client Pool API](../../nativeclient/connection-pools/native-client-pool-api.html)** - - The Geode native client API allows your clients to create and manage connection pools. The server side does not have an API. - -- **[Pool Configuration Example and Settings](../../nativeclient/connection-pools/configuring-pools-attributes-example.html)** - - Connection pools require standard client/server distributed system and cache configuration settings. You must also configure settings for the locator, server, and pool elements. - -- **[Subscription Properties](../../nativeclient/connection-pools/subscription-properties.html)** - - Each connection pool has a single subscription connection that can be to any server that matches the requirements of the connection pool. - -- **[Running the Connection Pool Code](../../nativeclient/connection-pools/running-connection-pool-code.html)** - - 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. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/connection-pools/connection-pools.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/connection-pools/connection-pools.html.md.erb b/geode-docs/nativeclient/connection-pools/connection-pools.html.md.erb deleted file mode 100644 index ef6547a..0000000 --- a/geode-docs/nativeclient/connection-pools/connection-pools.html.md.erb +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: Using Connection Pools ---- - -*Using Connection Pools* describes how connection pools achieve load balancing for the client and describes how to configure connection pools as server locators or as a list of servers. - -- **[How Client Load Balancing Works](../../nativeclient/connection-pools/client-load-balancing.html)** - - In a distributed system, servers can be added or removed and their capacity to service new client connections may vary. The server connectivity options are specified in the connection pool configuration. - -- **[Configuring Pools](../../nativeclient/connection-pools/configuring-pools.html)** - - A pool can be configured as locators or as a list of servers. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/connection-pools/discovering-locators-dynamically.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/connection-pools/discovering-locators-dynamically.html.md.erb b/geode-docs/nativeclient/connection-pools/discovering-locators-dynamically.html.md.erb deleted file mode 100644 index ed9ee6a..0000000 --- a/geode-docs/nativeclient/connection-pools/discovering-locators-dynamically.html.md.erb +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Discovering Locators Dynamically ---- - -A background thread periodically queries the locator for any other locators joining the distributed system. - -However, if locator A (to which the client is connected) goes down before it discovers locator B, locator B is never discovered even though it is alive and the client receives a `NoLocatorsAvailable` exception. - -One connection is attached to every application thread that is `local` to the respective thread. This is known as a thread local connection. - -In this case, to perform any cache operation the client is not required to obtain a connection from pool. Instead the thread local connection of the client is used. - -A thread local connection can be released by invoking the `Pool::releaseThreadLocalConnection()` method. The released connection is returned to the pool. If the number of threads is larger than the number of `max-connections`, the client throws an `AllConnectionsInUseException` after the `free-connection-timeout` lapses, unless the `Pool::releaseThreadLocalConnection()` method is used judiciously. - -If a connection expires or the server goes down on which the connection was established, a thread local connection is immediately replaced with a good connection obtained from the pool. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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/incubator-geode/blob/381d0faa/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`. - -
