http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/introduction/developing-solaris.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/introduction/developing-solaris.html.md.erb b/geode-docs/nativeclient/introduction/developing-solaris.html.md.erb deleted file mode 100644 index da707bc..0000000 --- a/geode-docs/nativeclient/introduction/developing-solaris.html.md.erb +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Developing C++ Programs on Solaris ---- - -This section describes how to build and run a native client application on Solaris. - -## <a id="developing-solaris__section_B518757C7D7A405F9E43C1232C2D6B56" class="no-quick-link"></a>Step 1. Set Environment Variables - -**Note:** When compiling external projects or applications that are used or referenced by the native client, make sure that you compile them for the same target architecture as your native client installation. For example, if you installed the 32-bit (x86) version of the native client, compile your external projects for 32-bit (x86) architecture. - -Set the native client environment variables on each Solaris host. For each case, *<productDir>* is the path to the native client product directory. - -**For Bourne and Korn shells (sh, ksh, bash)** - -``` pre -GFCPP=<productDir>; export GFCPP -PATH=$GFCPP/bin:$PATH;export PATH -LD_LIBRARY_PATH=$GFCPP/lib:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH -``` - -## <a id="developing-solaris__section_15D24DFEFE024690A2652A4DC17EFFFB" class="no-quick-link"></a>Step 2. Compile C++ Clients and Dynamically Link to Them to Native Client Library - -Version 5.9 of the *SUNpro* compiler is supported on Solaris. The linker switches vary according to whether you are statically linking to the native client library. - -To build and link a C++ client on Solaris, the compilation command line must include the appropriate arguments from this table. - -<a id="developing-solaris__table_428EFC82036240CA974E3061E5D31CCF"></a> - -| Argument | Explanation | -|------------------------------------------------------------------------------------------------|------------------------------------------------------------| -| `-D_REENTRANT` | Required to compile Solaris programs in a thread-safe way. | -| `-xarch=v8plus` | Enables 32-bit compilation. | -| `-xarch=v9` | Enables 64-bit compilation. | -| `-ldl`; `-lpthread`; `-lc`; `-lm`; `-lsocket`; `-lrt`; `-lnsl`; `-ldemangle`; `-lkstat`; `-lz` | Additional libraries. | -| `-library=stlport4` | Solaris library compilation. | -| `-I$ GFCPP /include` | Specifies the GemFire include directory. | - - - -## <a id="developing-solaris__section_81557A11797047A7941B47D44D1566AA" class="no-quick-link"></a>Step 3. Make Sure the Native Client Library Can Be Loaded - -When a C++ application is not statically linked to the native client library, the library must be dynamically loadable. - -To verify that the native client library is available for loading, make sure you have added the path *productDir*`/lib` to the *LD\_LIBRARY\_PATH* environment variable, where *productDir* is the path to the Geode product directory.
http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/introduction/developing-windows.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/introduction/developing-windows.html.md.erb b/geode-docs/nativeclient/introduction/developing-windows.html.md.erb deleted file mode 100644 index 7ed37c0..0000000 --- a/geode-docs/nativeclient/introduction/developing-windows.html.md.erb +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: Developing C++ Programs on Windows ---- - -Geode uses the Visual Studio 2010 Service Pack 1 compiler for C++ programs on Windows, which invokes Microsoft<sup>®</sup> `cl.exe` from the command line at compile time. - -The Geode native client supports .NET 4.0 and Visual Studio 2010. For advantages and more information on the features of .NET 4.0 and Visual Studio 2010 SP1, see [http://msdn.microsoft.com/en-us/library/dd831853(v=vs.100).aspx](http://msdn.microsoft.com/en-us/library/dd831853(v=vs.100).aspx) and [http://msdn.microsoft.com/en-us/library/vstudio/w0x726c2(v=vs.100).aspx](http://msdn.microsoft.com/en-us/library/vstudio/w0x726c2(v=vs.100).aspx). - -Visual Studio 2010 SP1 is the recommended compiler. If you are using any other compiler, contact technical support for assistance. - -**Note:** When compiling external projects or applications that are used or referenced by the native client, make sure that you compile them for the same target architecture as your native client installation. For example, if you installed the 32-bit (x86) version of the native client, compile your external projects for 32-bit (x86) architecture. - -## <a id="developing-windows__section_6BFD4982A7144301A03F948CFF953AFD" class="no-quick-link"></a>Step 1. Installer Sets Up Environment Variables - -When you install on Windows, the installer performs these tasks: - -- Sets the *GFCPP* environment variable to *<productDir>*, where *<productDir>* is the path to the native client product directory. -- Adds the *%GFCPP%\\bin* executable directory to the Windows *PATH*. - -## <a id="developing-windows__section_0BF2BE9A38BC40D1B9FAD2AC8DBFAB0E" class="no-quick-link"></a>Step 2. Choose 32-bit or 64-bit Command-line Prompt - -For 32-bit: - -Start > Programs > Microsoft Visual Studio > 2010 > Visual Studio Tools > Visual Studio 2010 Command Prompt - -For 64-bit: - -Start > Programs > Microsoft Visual Studio 2010 > Visual Studio Tools > Visual Studio 2010 x64 Win64 Command Prompt - -To build using the Microsoft Visual Studio Interface, from the Solutions Platform, choose **Win32** or **x86** from the Build menu for 32-bit builds or x64 for a 64-bit build. - -## <a id="developing-windows__section_597B20DBE5FD4F66A6BCB2A09C04C9C9" class="no-quick-link"></a>Step 3. Compile C++ Clients and Dynamically Link Them to Native Client Library - -The following table lists the compiler and linker switches that must be present on the `cl.exe` command line. - -**Note:** -If you want to use the Visual Studio user interface instead of invoking `cl.exe` from the command line, be sure to supply these parameters. - -<a id="developing-windows__table_1FE5C01E91424CE9906CA1D0210B1237"></a> - -| Argument | Explanation | -|-----------------------------------|-----------------------------------------------------------------------------------------------------------------------| -| `/MD` | Memory model. | -| `/EHsc` | Catches C++ exceptions only and tells the compiler to assume that \*extern\* C functions never throw a C++ exception. | -| `/GR` | Runtime type information. | -| `-I%GFCPP%\include` | Specifies the Geode `include` directory. | -| `%GFCPP%\lib\gfcppcache.lib` | Specifies the library file for the shared library. | -| `/D_CRT_SECURE_NO_DEPRECATE` | Suppresses warnings. Required for Visual Studio 2010. | -| `/D_CRT_NON_CONFORMING_SWPRINTFS` | Suppresses warnings. Required for Visual Studio 2010. | - - -## <a id="developing-windows__section_B66588EC7C6F4D9BA772406CFD5F3EAE" class="no-quick-link"></a>Step 4. Verify that You Can Load the Native Client Library - -Because Geode does not provide a library that can be linked statically into an application on Windows, you must dynamically link to the native client library. - -To make the native client library available for loading, verify that the directory `productDir/bin` is included in the *PATH* environment variable, where *productDir* is the path to the Geode product directory. http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/introduction/examples-quickstart.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/introduction/examples-quickstart.html.md.erb b/geode-docs/nativeclient/introduction/examples-quickstart.html.md.erb deleted file mode 100644 index 3708859..0000000 --- a/geode-docs/nativeclient/introduction/examples-quickstart.html.md.erb +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: QuickStart Examples and Guide ---- - -Run the native client QuickStart examples and read the QuickStart Guide to understand native client functionality. - -- **[Running the QuickStart Examples](../../nativeclient/introduction/product-examples.html)** - - The QuickStart examples demonstrate the capabilities of the native client, and they provide source code so you can examine how each example is designed. C++ and C\# examples demonstrate how the native client performs as a C++ or C\# client. - -- **[Accessing the QuickStart Guide](../../nativeclient/introduction/quickstart.html)** - - The QuickStart Guide for the native client consists of a set of compact programming samples that demonstrate both C++ and C\# client operations. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/introduction/install-overview.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/introduction/install-overview.html.md.erb b/geode-docs/nativeclient/introduction/install-overview.html.md.erb deleted file mode 100644 index e20cd42..0000000 --- a/geode-docs/nativeclient/introduction/install-overview.html.md.erb +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Installing the Native Client ---- - -Procedures for installing the native client will be here, once they are written. They will vary according to your operating system. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/introduction/native-client-intro.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/introduction/native-client-intro.html.md.erb b/geode-docs/nativeclient/introduction/native-client-intro.html.md.erb deleted file mode 100644 index d787b40..0000000 --- a/geode-docs/nativeclient/introduction/native-client-intro.html.md.erb +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Getting Started with a Native Client ---- - -This section gives you a conceptual overview of the native client. It shows you how to install the product, build native client applications on various platforms, and run the product examples. - -The native client provides access for C++ and Microsoft<sup>®</sup> .NET⢠clients to a Geode distributed system. - -- **[About the Native Client](../../nativeclient/introduction/native-client-overview.html)** - - The native client delivers the full set of capabilities supplied by Java clients communicating with a Geode server. - -- **[Installing the Native Client](../../nativeclient/introduction/install-overview.html)** - - Procedures for installing the native client will be here, once they are written. They will vary according to your operating system. - -- **[Running Native Client Applications](../../nativeclient/introduction/runnng-client-apps.html)** - - Set up the environment for the native client on multiple platforms. Compile and run client programs. - -- **[QuickStart Examples and Guide](../../nativeclient/introduction/examples-quickstart.html)** - - Run the native client QuickStart examples and read the QuickStart Guide to understand native client functionality. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/introduction/native-client-overview.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/introduction/native-client-overview.html.md.erb b/geode-docs/nativeclient/introduction/native-client-overview.html.md.erb deleted file mode 100644 index 467aa81..0000000 --- a/geode-docs/nativeclient/introduction/native-client-overview.html.md.erb +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: About the Native Client ---- - -The native client delivers the full set of capabilities supplied by Java clients communicating with a Geode server. - -The native client is written entirely in C++, so its initialization process does not involve the creation of a Java virtual machine. The .NET native client provides native operations for the .NET Framework application developer who writes in .NET languages and needs to access the Geode server. - -Native clients in C++, Java, and .NET languages communicate only with the cache server and do not communicate with each other. The native clients interface with the server at the sockets level and implement the same wire protocol to the server. These capabilities produce extremely high performance and system scalability. - -C++ and .NET native clients provide access to the full region API, including support for application plug-ins, managed connectivity, highly available data, and reliable failover to a specified server list. All of this is transparent to the end user. - -You can configure native clients to cache data locally, or they can act in a cacheless mode where they retrieve data from a cache server and directly pass it to other system members without incurring the caching overhead. They can be configured as read only caches, or be configured to receive notifications from the server whenever a key of interest to the client changes on the server. - -This figure diagrams how .NET and C++ applications access the cache server. <a id="concept_BCE696D352144690ADF786A0E3D2BD98__fig_C19B4B30942D4F1BA59DBDCC6146241A"></a> - - -<img src="../common/images/native-client-overview.gif" alt="Native Client Overview" id="concept_BCE696D352144690ADF786A0E3D2BD98__image_A0805B5079C64B0E8F2E9DA2A8A5A7A6" class="image" /> - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/introduction/product-examples.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/introduction/product-examples.html.md.erb b/geode-docs/nativeclient/introduction/product-examples.html.md.erb deleted file mode 100644 index 60c131c..0000000 --- a/geode-docs/nativeclient/introduction/product-examples.html.md.erb +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Running the QuickStart Examples ---- - -The QuickStart examples demonstrate the capabilities of the native client, and they provide source code so you can examine how each example is designed. C++ and C\# examples demonstrate how the native client performs as a C++ or C\# client. - -Read the QuickStart Guide first (the `README.HTML` file included with the QuickStart examples) to learn more about running the QuickStart examples. - -QuickStart examples are packaged as part of the native client product download. Product examples are installed into the following directory when you install the Geode native client: - -``` pre -<native_client_installdir>/SampleCode/quickstart -``` - -where *native\_client\_installdir* is the location where you installed the Geode native client. - -**Note:** The C\# examples have a `.config` file that should not be modified or deleted. The file provides references to support files for running the example. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/introduction/quickstart.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/introduction/quickstart.html.md.erb b/geode-docs/nativeclient/introduction/quickstart.html.md.erb deleted file mode 100644 index c72f496..0000000 --- a/geode-docs/nativeclient/introduction/quickstart.html.md.erb +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Accessing the QuickStart Guide ---- - -The QuickStart Guide for the native client consists of a set of compact programming samples that demonstrate both C++ and C\# client operations. - -Open the QuickStart Guide to rapidly become familiar with native client functionality. To view the QuickStart Guide, navigate to the `SampleCode/quickstart` directory of your Geode native client installation, and open the `README.html` file. - -The `README.html` file describes each programming sample, explains initial environment setup, and provides instructions for running the QuickStart examples. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/introduction/runnng-client-apps.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/introduction/runnng-client-apps.html.md.erb b/geode-docs/nativeclient/introduction/runnng-client-apps.html.md.erb deleted file mode 100644 index db40094..0000000 --- a/geode-docs/nativeclient/introduction/runnng-client-apps.html.md.erb +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Running Native Client Applications ---- - -Set up the environment for the native client on multiple platforms. Compile and run client programs. - -- **[Developing C++ Programs on Linux](../../nativeclient/introduction/developing-linux.html)** - - This section describes how to build and run a native client application on Linux. - -- **[Developing C++ Programs on Solaris](../../nativeclient/introduction/developing-solaris.html)** - - This section describes how to build and run a native client application on Solaris. - -- **[Developing C++ Programs on Windows](../../nativeclient/introduction/developing-windows.html)** - - Geode uses the Visual Studio 2010 Service Pack 1 compiler for C++ programs on Windows, which invokes Microsoft<sup>®</sup> `cl.exe` from the command line at compile time. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/app-ops-during-int-reg.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/app-ops-during-int-reg.html.md.erb b/geode-docs/nativeclient/preserving-data/app-ops-during-int-reg.html.md.erb deleted file mode 100644 index dcf5717..0000000 --- a/geode-docs/nativeclient/preserving-data/app-ops-during-int-reg.html.md.erb +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Application Operations During Interest Registration ---- - -As soon as the client creates its regions, the application hosting the client can start cache operations, even while the client is still receiving its interest registration responses. - -In that case, application operations take precedence over interest registration responses. - -When adding register interest responses to the cache, the following rules are applied: - -- If the entry already exists in the cache with a valid value, it is not updated. -- If the entry is invalid and the register interest response is valid, the valid value is put into the cache. -- If an entry is marked destroyed, it is not updated. Destroyed entries are removed from the system after the register interest response is completed. - -If the interest response does not contain any results because all of those keys are absent from the serverâs cache, the clientâs cache can start out empty. If the queue contains old messages related to those keys, the events are still replayed in the clientâs cache. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/client-side-config.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/client-side-config.html.md.erb b/geode-docs/nativeclient/preserving-data/client-side-config.html.md.erb deleted file mode 100644 index b2cc5c5..0000000 --- a/geode-docs/nativeclient/preserving-data/client-side-config.html.md.erb +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Client-Side Configuration ---- - -All durable messaging configurations are performed on the client. - -- **[Configuring a Durable Native Client](../../nativeclient/preserving-data/configuring-durable-nc.html)** - - The durable native client can be configured in the `gfcpp.properties` file, or in the `CacheFactory::set(name, value)` call. - -- **[Configuring Durable Interest in Keys](../../nativeclient/preserving-data/config-durable-interest-keys.html)** - - When a durable client disconnects, its servers keep queuing messages for selected keys. The client indicates which keys by registering durable interest for those keys. - -- **[Configuring Durable Client Reconnection](../../nativeclient/preserving-data/config-durable-reconnect.html)** - - You can configure the durable native client to obtain an approximate count of pending events upon durable client reconnection. Based on the returned number, you can determine whether to proceed and receive the pending events or to close the cache. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/config-durable-interest-keys.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/config-durable-interest-keys.html.md.erb b/geode-docs/nativeclient/preserving-data/config-durable-interest-keys.html.md.erb deleted file mode 100644 index e0395e2..0000000 --- a/geode-docs/nativeclient/preserving-data/config-durable-interest-keys.html.md.erb +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: Configuring Durable Interest in Keys ---- - -When a durable client disconnects, its servers keep queuing messages for selected keys. The client indicates which keys by registering durable interest for those keys. - -This fine-grained control handles the constraints of queue size and memory by saving only the critical messages. - -You still register interest for other keys, but not durable interest. When the client is connected to its servers, it receives messages for those non-durable keys. When the client is disconnected, its non-durable interest registrations are deleted but messages that are already in the queue remain there. - -For durable clients, all interest registration is done immediately after the regions are created. This is required whether interest registration is durable or not durable. An extra `registerInterest` parameter specified for durable clients indicates whether the registration is durable (true) or not (false). - -## API Client Durable Interest List Registration (C++) - -The following programmatic example registers durable interest in Key-1. The interest registration happens immediately after region creation and before anything else. - -``` pre -// Durable client interest registration can be -// durable (true) or nondurable(default). -VectorOfCacheableKey keys; -keys.push_back( CacheableString::create("Key-1") ); -regionPtr->registerKeys(keys,true); -``` - -<a id="concept_6456354A9AD945C780A5AA864B41B564__section_3DE5872B0888410EB42D52CFB28C79E5"></a> -You use the typical methods for interest registration and configure notification by subscription on the server as usual. For details, see [Registering Interest for Entries](../client-cache/registering-interest-for-entries.html#registering-interest-for-entries). - -**Note:** -Changing interest registration after the durable client connects the first time can cause data inconsistency and is not recommended. - -At restart, if the client doesn't register durable interest for exactly the same keys as before then the entries in the interest list are not copied from the server during the registration. Instead, the client cache starts out empty and entries are added during updates. If no updates come in for an entry, it never shows up in the client cache. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/config-durable-reconnect.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/config-durable-reconnect.html.md.erb b/geode-docs/nativeclient/preserving-data/config-durable-reconnect.html.md.erb deleted file mode 100644 index 20c2359..0000000 --- a/geode-docs/nativeclient/preserving-data/config-durable-reconnect.html.md.erb +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Configuring Durable Client Reconnection ---- - -You can configure the durable native client to obtain an approximate count of pending events upon durable client reconnection. Based on the returned number, you can determine whether to proceed and receive the pending events or to close the cache. - -Use the `getPendingEventCount` (C++ API) and the `PendingEventCount` (C\# .NET API) property to detect whether the previously registered subscription queue is available upon durable client reconnection and the count of pending events in the queue. Based on the returned results, you can then decide whether to receive the remaining events or close the cache if the number is too large. - -For example, consider this code fragment for a client with only the default pool created: - -``` pre -Pool pool = PoolManager.Find("PoolName"); -int pendingEvents = pool.PendingEventCount; -if (pendingEvents == -2) { // client connected for the first time - ⦠// continue -} else if (pendingEvents == -1) { // client reconnected but after the timeout period - ⦠// handle possible data loss -} else { // pendingEvents >= 0 - // decide to invoke readyForEvents() or Cache.close(false)/Pool.destroy() -} -``` - -For a client with multiple pools: - -``` pre -int pendingEvents = 0; -int pendingEvents1 = PoolManager.Find(âpool1â).PendingEventCount; -pendingEvents += (pendingEvents1 > 0) ? pendingEvents1 : 0; -int pendingEvents2 = PoolManager.Find(âpool2â).PendingEventCount; -pendingEvents += (pendingEvents2 > 0) ? pendingEvents2 : 0; -// process individual pool counts separately -``` - -The `getPendingEventCount` method and PendingEventCount property can return the following possible values: - -- A value representing a count of events pending at the server. Note that this count is an approximate value based on the time the durable client pool connected or reconnected to the server. Any number of invocations will return the same value. -- A zero value if there are no events pending at server for this client pool -- A negative value indicates that no queue is available at the server for the client pool. - - A value of -1 indicates that the client pool has reconnected to the server after its durable-client-timeout period has elapsed. The pool's subscription queue has been removed possibly causing data loss. - - A value of -2 indicates that this client pool has connected to server for the first time. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/configuring-durable-nc.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/configuring-durable-nc.html.md.erb b/geode-docs/nativeclient/preserving-data/configuring-durable-nc.html.md.erb deleted file mode 100644 index 2d85021..0000000 --- a/geode-docs/nativeclient/preserving-data/configuring-durable-nc.html.md.erb +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Configuring a Durable Native Client ---- - -The durable native client can be configured in the `gfcpp.properties` file, or in the `CacheFactory::set(name, value)` call. - -- **Durable client ID**âYou indicate that the client is durable by giving it a `durable-client-ID`. The servers use this ID to identify the client. For a non-durable client, the `durable-client-ID` is an empty string. The ID can be any number that is unique among the clients attached to servers in the same distributed system. - -- **Durable timeout**âThe `durable-timeout` setting specifies how long this clientâs servers should wait after the client disconnects before terminating its message queue. During that time, the servers consider the client alive and continue to accumulate messages for it. The default is 300 seconds. - -The `durable-timeout` setting is a tuning parameter. When setting the timeout, take into account the normal activity of your application, the average size of your messages, and the level of risk you can handle. Assuming that no messages are being removed from the queue, how long can the application run before the queue reaches the maximum message count? In addition, how long can it run before the queued messages consume all the memory on the client host? How serious is each of those failures to your operation? - -To assist with tuning, Geode provides statistics that track message queues for durable clients through the disconnect and reconnect cycles. For statistics documentation, see [Statistics](../../managing/statistics/chapter_overview.html). - -When the queue is full, it blocks further operations that add messages until the queue size drops to an acceptable level. The action to take is specified on the server. For details on configuring the queue, see [Implementing Durable Client/Server Messaging](../../developing/events/implementing_durable_client_server_messaging.html). - -## Configuring a Durable Native Client Using gfcpp.properties - -The following example shows `gfcpp.properties` settings to make the client durable and set the durable timeout to 200seconds. - -``` pre -durable-client-id=31 -durable-timeout=200 -``` - -## Configuring a Durable Client Through the API (C++) - -This programmatic example creates a durable client using the `CacheFactory::set(name, value)`. - -``` pre -// Create durable client's properties using the C++ api -PropertiesPtr pp = Properties::create(); -pp->insert("durable-client-id", "DurableClientId"); -pp->insert("durable-timeout", 200); -cacheFactoryPtr = CacheFactory::createCacheFactory(pp); -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/configuring-nc-ha.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/configuring-nc-ha.html.md.erb b/geode-docs/nativeclient/preserving-data/configuring-nc-ha.html.md.erb deleted file mode 100644 index 6e55991..0000000 --- a/geode-docs/nativeclient/preserving-data/configuring-nc-ha.html.md.erb +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Configuring Native Clients for High Availability ---- - -Configure high availability by setting the pool attribute `subscription-redundancy` to the number of copies you want maintained. - -A client maintains its queue redundancy level at the time of a primary server failure by connecting to additional secondary servers. - -<a id="concept_7CEFF513CED14397A385ED88F3287AF1__section_BC1693F33FA1448296C00220962EDDEE"></a> -Native clients can specify the number of secondary servers where the client registers interest and maintains subscription channels, in addition to the subscription channel with the primary server. The secondary servers maintain redundant update queues for the client. If the primary server fails, a secondary becomes a primary to provide uninterrupted messaging to the client. If possible, another secondary is then initialized so the total number of secondaries is not reduced by the failover. - -## Setting the Server Redundancy Level in cache.xml - -This example sets one redundant server as failover backup to the primary server: - -``` pre -<cache> - <pool name="examplePool" - subscription-enabled="true" subscription-redundancy="1"> - <server host="java_servername1" port="java_port1" /> - <server host="java_servername2" port="java_port2" /> - </pool> - <region name = "ThinClientRegion1" > - <region-attributes refid="CACHING_PROXY" pool-name="examplePool"/> - </region> -</cache> -``` - -## Setting the Server Redundancy Level Programmatically - -You can set the redundancy level programmatically. This example creates a client cache with two redundant cache servers configured in addition to the primary server. - -The server redundancy level can be configured using the pool API. For more information about the pool API, see [Using Connection Pools](../connection-pools/connection-pools.html#using-connection-pools). - -``` pre -PropertiesPtr pp = Properties::create( ); -systemPtr = CacheFactory::createCacheFactory(pp); -// Create a cache. -cachePtr = systemPtr->setSubscriptionEnabled(true) - ->addServer("localhost", 24680) - ->addServer("localhost", 24681) - ->addServer("localhost", 24682) - ->setSubscriptionRedundancy(2) - ->create(); -``` - -When failover to a secondary server occurs, a new secondary is added to the redundancy set. If no new secondary server is found, the redundancy level is not satisfied but the failover procedure completes successfully. Any new live server is added as a secondary and interest is registered on it. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/disconnecting-from-server.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/disconnecting-from-server.html.md.erb b/geode-docs/nativeclient/preserving-data/disconnecting-from-server.html.md.erb deleted file mode 100644 index d311e08..0000000 --- a/geode-docs/nativeclient/preserving-data/disconnecting-from-server.html.md.erb +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Disconnecting from the Server ---- - -When a durable client closes its cache and disconnects, it tells the servers whether to maintain its queues. - -For this purpose, use the version of `Cache::close` with the boolean `keepalive` parameter set, as shown in the following example. If the setting is true, the servers keep the durable clientâs queues and durable subscriptions alive for the timeout period. In addition to in-memory queue retention, the servers can evict the most recent durable client queue updates to disk to reduce memory consumption. - -Only the resources and data related to the session are removed, such as port numbers and non-durable subscriptions. If the setting is false, the servers do the same cleanup that they would do for a nondurable client. - -## Durable Client Disconnect With Queues Maintained - -``` pre -// Close the Cache and disconnect with keepalive=true. -// Server will queue events for durable registrations and CQs -// When the client reconnects (within a timeout period) and sends -// "readyForEvents()", the server will deliver all stored events -cachePtr->close(true); -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/disconnection.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/disconnection.html.md.erb b/geode-docs/nativeclient/preserving-data/disconnection.html.md.erb deleted file mode 100644 index ac653ba..0000000 --- a/geode-docs/nativeclient/preserving-data/disconnection.html.md.erb +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Disconnection ---- - -While the client and servers are disconnected, their operation varies depending on the circumstances. - -## <a id="concept_915EAD135DD942F28A38513097ACB1F1__section_6AB8F4B8993F4EF9B32A93A100F07BEC" class="no-quick-link"></a>Normal disconnect - -When a durable client disconnects normally, the `Cache.close` request states whether to maintain the client's message queue and durable subscriptions. The servers stop sending messages to the client and release its connection. See[Disconnecting From the Server](disconnecting-from-server.html#concept_3A9AC62F96FA44DBBB5CCBFD3EA19B56) for more information. - -If requested, the servers maintain the queues and durable interest list until the client reconnects or times out. The non-durable interest list is discarded. The servers continue to queue up incoming messages for entries on the durable interest list. All messages that were in the queue when the client disconnected remain in the queue, including messages for entries on the non-durable list. - -If the client requests to not have its subscriptions maintained, or if there are no durable subscriptions, the servers unregister the client and perform the same cleanup as for a non-durable client. - -## Abnormal disconnect - -If the client crashes or loses its connections to all servers, the servers automatically maintain its message queue and durable subscriptions until the client reconnects or times out. - -## Client disconnected but operational - -If the client operates while it is disconnected, it gets what data it can from the local cache. Since updates are not allowed, the data can become stale. An `UnconnectedException` occurs if an update is attempted. - -## Timing out while disconnected - -The servers track how long to keep a durable client queue alive based on the `durable-client-timeout` setting. If the client remains disconnected longer than the timeout, the servers unregister the client and do the same cleanup that is performed for a non-durable client. The servers also log an alert. When a timed-out client reconnects, the servers treat it as a new client making its initial connection. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/durable-client-life-cycle.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/durable-client-life-cycle.html.md.erb b/geode-docs/nativeclient/preserving-data/durable-client-life-cycle.html.md.erb deleted file mode 100644 index 67ba0f8..0000000 --- a/geode-docs/nativeclient/preserving-data/durable-client-life-cycle.html.md.erb +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Life Cycle of a Durable Client ---- - -This section discusses the high-level operation of a durable client through initial startup, disconnection, and reconnection. - -- **[Initial Operation](../../nativeclient/preserving-data/initial-operation.html)** - - The initial startup of a durable client is similar to the startup of any other client, except that it specifically calls the `Cache.readyForEvents` method when all regions and listeners on the client are ready to process messages from the server. - -- **[Disconnection](../../nativeclient/preserving-data/disconnection.html)** - - While the client and servers are disconnected, their operation varies depending on the circumstances. - -- **[Reconnection](../../nativeclient/preserving-data/reconnection.html)** - - During initialization, operations on the client cache can come from multiple sources. - -- **[Durable Message Replay](../../nativeclient/preserving-data/durable-message-replay.html)** - - When the primary server receives the cache ready message, the servers and client execute a procedure to update the queue and replay the events from the stored messages. - -- **[Application Operations During Interest Registration](../../nativeclient/preserving-data/app-ops-during-int-reg.html)** - - As soon as the client creates its regions, the application hosting the client can start cache operations, even while the client is still receiving its interest registration responses. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/durable-client-messaging-req.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/durable-client-messaging-req.html.md.erb b/geode-docs/nativeclient/preserving-data/durable-client-messaging-req.html.md.erb deleted file mode 100644 index 691ad30..0000000 --- a/geode-docs/nativeclient/preserving-data/durable-client-messaging-req.html.md.erb +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Durable Client Messaging Requirements ---- - -The messaging queues used for durable messaging are the same regular messaging queues used for basic server-to-client messaging, with additional requirements. - -See [Implementing Durable Client/Server Messaging](../../developing/events/implementing_durable_client_server_messaging.html) for requirements, options, and functionality of messaging queues. If you are using highly available servers, see [High Availability for Client-Server Communication](high-availability-client-server.html#concept_F7A143F51EEA46B28AC612DEB7849D99)for additional requirements. - -For durable client messaging, you also need the following: - -- **Durable clients**. If the client is durable, the server continues to maintain the client queues when the client disconnects. - **Note:** - Redundancy management is handled by the client, so when the client is disconnected from the server the redundancy of client events is not maintained. Even if the servers fail one at a time, so that running clients have time to fail over and pick new secondary servers, an offline durable client cannot fail over. As a result, the client loses its queued messages. - -- **Durable interest registration**. A durable clientâs interest registrations specify whether its interest in a key is durable. If it is, the servers continue queuing messages for that key while the client is disconnected. -- **Reconnection conditions.** You can program the durable client to detect whether the previously registered subscription queue is available upon reconnection and determine an approximate count of pending events in the queue. Based on the results, you can then decide whether to receive the remaining events (`Cache.readyForEvents`) or close the cache if the number is too large. -- **Cache ready message**. When it is ready to receive the stored messages, a durable client must call `Cache.readyForEvents` to send a cache ready message to the server. -- **Disconnect keepalive specification**. When a durable client disconnects normally it must tell the server whether to maintain the message queue or delete it. -- **Durable client callback method**. If you use cache listeners on the durable clients, you have the option to implement the `afterRegionLive` callback method. This callback is invoked after the durable client connects to its servers, when it has received all of its stored messages and replayed the events. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/durable-client-messaging.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/durable-client-messaging.html.md.erb b/geode-docs/nativeclient/preserving-data/durable-client-messaging.html.md.erb deleted file mode 100644 index 9ae99d1..0000000 --- a/geode-docs/nativeclient/preserving-data/durable-client-messaging.html.md.erb +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Durable Client Messaging ---- - -You can configure the redundancy level for client queues that are stored on cache servers. This ensures that the client will not lose messages if it loses the connection to its primary server. - -Durable messaging allows a disconnected client application to recover its subscribed data when it reconnects to the cache server because the server continues to queue messages for which the client has registered interest. - -- **[Durable Client Messaging Requirements](../../nativeclient/preserving-data/durable-client-messaging-req.html)** - - The messaging queues used for durable messaging are the same regular messaging queues used for basic server-to-client messaging, with additional requirements. - -- **[Client-Side Configuration](../../nativeclient/preserving-data/client-side-config.html)** - -- **[Sending Cache Ready Messages to the Server](../../nativeclient/preserving-data/sending-cache-ready-message.html)** - - After a durable client connects and initializes its cache, regions, cache listeners, and any interest registration, it invokes `readyForEvents` to indicate to the servers that the client is ready to receive any messages accumulated for it. - -- **[Disconnecting from the Server](../../nativeclient/preserving-data/disconnecting-from-server.html)** - - When a durable client closes its cache and disconnects, it tells the servers whether to maintain its queues. - -- **[Life Cycle of a Durable Client](../../nativeclient/preserving-data/durable-client-life-cycle.html)** - - This section discusses the high-level operation of a durable client through initial startup, disconnection, and reconnection. - -- **[Implementing Cache Listeners for Durable Clients](../../nativeclient/preserving-data/impl-cache-listeners-durable-clients.html)** - - A cache listener for durable clients requires all callback methods to behave properly when stored events are replayed. A cache listener has a callback method, `afterRegionLive`, specifically for durable clients aspects. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/durable-message-replay.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/durable-message-replay.html.md.erb b/geode-docs/nativeclient/preserving-data/durable-message-replay.html.md.erb deleted file mode 100644 index c4274ca..0000000 --- a/geode-docs/nativeclient/preserving-data/durable-message-replay.html.md.erb +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Durable Message Replay ---- - -When the primary server receives the cache ready message, the servers and client execute a procedure to update the queue and replay the events from the stored messages. - -Durable message replay proceeds as follows. To avoid overwriting current entries with old data, the client does not apply the updates to its cache. - -1. The server finds the queue for this durable client ID and updates its information, including the clientâs socket and remote ports. - - If the client has timed out while it was disconnected, its queues are gone and the server then treats it as a new client. See [Initial Operation](initial-operation.html). - -2. All servers that have a queue for this client place a marker in the queue. - - Messages in the queue before the marker are considered to have come while the client was disconnected. Messages after the marker are handled normally. - -3. The cache server sends the queued messages to the client. This includes any messages that were evicted to disk. -4. The client receives the messages but does not apply the updates to its cache. If cache listeners are installed, they handle the events. For implications, see [Implementing Cache Listeners for Durable Clients](impl-cache-listeners-durable-clients.html#concept_3BD651087FC4470C8BAB6AFD97AEA689). -5. The client receives the marker message indicating that all past events have been played back. -6. The cache server sends the current list of live regions. -7. In each live region on the client, the marker event triggers the `afterRegionLive` callback. - - After the callback, the client begins normal processing of events from the server and applies the updates to its cache. - -Even when a new client starts up for the first time, the cache ready markers are inserted in the queues. If messages start coming into the new queues before the servers insert the marker, those messages are considered as having happened while the client was disconnected, and their events are replayed the same as in the reconnect case. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/high-availability-client-server.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/high-availability-client-server.html.md.erb b/geode-docs/nativeclient/preserving-data/high-availability-client-server.html.md.erb deleted file mode 100644 index 1007886..0000000 --- a/geode-docs/nativeclient/preserving-data/high-availability-client-server.html.md.erb +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: High Availability for Client-Server Communication ---- - -The Geode native client provides reliable event messaging from cache server to client to prevent data loss during server failover operations. High availability is implemented in the cache server and is configured in the native client. - -See [Configuring Highly Available Servers](../../developing/events/configuring_highly_available_servers.html) for details about configuring a Java cache server for high availability. - -**Note:** -High availability functions the same whether the region is partitioned or not. See [Partitioned Regions](../../developing/partitioned_regions/chapter_overview.html) for information about partitioned regions. - -- **[Configuring Native Clients for High Availability](../../nativeclient/preserving-data/configuring-nc-ha.html)** - - Configure high availability by setting the pool attribute `subscription-redundancy` to the number of copies you want maintained. - -- **[Sending Periodic Acknowledgment](../../nativeclient/preserving-data/sending-periodic-ack.html)** - - Servers use periodic acknowledgment to reduce the likelihood of duplicate notifications, and to reduce resource usage. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/impl-cache-listeners-durable-clients.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/impl-cache-listeners-durable-clients.html.md.erb b/geode-docs/nativeclient/preserving-data/impl-cache-listeners-durable-clients.html.md.erb deleted file mode 100644 index a91cb3b..0000000 --- a/geode-docs/nativeclient/preserving-data/impl-cache-listeners-durable-clients.html.md.erb +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Implementing Cache Listeners for Durable Clients ---- - -A cache listener for durable clients requires all callback methods to behave properly when stored events are replayed. A cache listener has a callback method, `afterRegionLive`, specifically for durable clients aspects. - -For general instructions on implementing a cache listener, see [CacheListener](../client-cache/application-plugins.html#application-plugins__section_3F43B898CD254076B4DD777E9B4CC8F0). - -## <a id="concept_3BD651087FC4470C8BAB6AFD97AEA689__section_EC28F9769A554CA28B0E9D2F924BA4C3" class="no-quick-link"></a>Writing Callbacks for Use With Durable Messaging - -Durable clients require special attention to cache callbacks generated by the cache listener. During the initialization window when a reconnecting client has a functioning cache but is still receiving the stored messages from the queue, the client can replay events that are long past. These events are not applied to the cache, but they are sent to the cache listener. If the listenerâs callbacks invoked by these events make changes to the cache, that could conflict with current operations and create data inconsistencies. - -Consequently, you need to keep your callback implementations lightweight and not do anything in the cache that could produce incorrect results during this window. For details on implementing callbacks for Geode event handlers, see[Implementing Cache Event Handlers](../../developing/events/implementing_cache_event_handlers.html). - -## <a id="concept_3BD651087FC4470C8BAB6AFD97AEA689__section_F39E695D88E94D518F3E1778F37FAF11" class="no-quick-link"></a>Implementing the afterRegionLive Method - -If you are using cache listeners, you can implement the `afterRegionLive` callback method provided for durable clients. This callback is invoked when the client has received all the old messages that were stored in its queue while it was disconnected. Implementing this method enables you to do application-specific operations when the client has replayed all of these old events. - -If you do not wish to use this callback, and your listener is an instance of `CacheListener` (not a `CacheListenerAdapter`), you must implement `afterRegionLive` as a non-operational method. http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/initial-operation.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/initial-operation.html.md.erb b/geode-docs/nativeclient/preserving-data/initial-operation.html.md.erb deleted file mode 100644 index c77d218..0000000 --- a/geode-docs/nativeclient/preserving-data/initial-operation.html.md.erb +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Initial Operation ---- - -The initial startup of a durable client is similar to the startup of any other client, except that it specifically calls the `Cache.readyForEvents` method when all regions and listeners on the client are ready to process messages from the server. - -See [Sending the Cache Ready Message to the Server](sending-cache-ready-message.html#concept_C28D015FA85B4EE4B2F8D2DA5FCAFBFF). - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/preserving-data.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/preserving-data.html.md.erb b/geode-docs/nativeclient/preserving-data/preserving-data.html.md.erb deleted file mode 100644 index ff851ad..0000000 --- a/geode-docs/nativeclient/preserving-data/preserving-data.html.md.erb +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Preserving Data ---- - -A server may preserve the data queued and intended to be sent to a native client, such that the data is not discarded if communication between the server and native client is disrupted. Preservation prevents message loss, which can cause a native client to have inconsistent data. Redundant queues and a high availability server implementation may further ensure that queued data is not lost. - -There is a tradeoff between the quantity of data that a server must queue and the amount of time that the server maintains and continues to queue data intended for a native client that is not communicating with the distributed system. Client configuration specifies the amount of time that the server is to continue queueing messages. High availability permits a secondary server to assume the role of a primary server with respect to queued data in the event that the primary server no longer functions. Designation of primary and secondary servers, as well as the number of redundant copies of the queue are configurable. - -- **[High Availability for Client-Server Communication](../../nativeclient/preserving-data/high-availability-client-server.html)** - - The Geode native client provides reliable event messaging from cache server to client to prevent data loss during server failover operations. High availability is implemented in the cache server and is configured in the native client. - -- **[Enabling Queue Conflation to Improve Update Performance](../../nativeclient/preserving-data/using-queue-conflation.html)** - - Conflation of entry update messages can reduce the number of update messages a native client receives, thereby increasing performance. The native client receives only the most recent update for a particular entry key. - -- **[Durable Client Messaging](../../nativeclient/preserving-data/durable-client-messaging.html)** - - You can configure the redundancy level for client queues that are stored on cache servers. This ensures that the client will not lose messages if it loses the connection to its primary server. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/reconnection.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/reconnection.html.md.erb b/geode-docs/nativeclient/preserving-data/reconnection.html.md.erb deleted file mode 100644 index a31f721..0000000 --- a/geode-docs/nativeclient/preserving-data/reconnection.html.md.erb +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Reconnection ---- - -During initialization, operations on the client cache can come from multiple sources. - -- Cache operations by the application. -- Results returned by the cache server in response to the clientâs interest registrations. -- Callbacks triggered by replaying old events from the queue. - -These procedures can act on the cache concurrently, and the cache is never blocked from doing operations. - -Geode handles the conflicts between the application and interest registration, but you need to prevent the callback problem. Writing callback methods that do cache operations is never recommended, but it is a particularly bad idea for durable clients, as explained in [Implementing Cache Listeners for Durable Clients](impl-cache-listeners-durable-clients.html). - -Program the durable client to perform these steps, in order, when it reconnects: - -1. Create the cache and regions. This ensures that all cache listeners are ready. At this point, the application hosting the client can begin cache operations. -2. Issue its register interest requests. This allows the client cache to be populated with the initial interest registration results. The primary server responds with the current state of those entries if they still exist in the serverâs cache. -3. Call `Cache.readyForEvents`. This tells the servers that all regions and listeners on the client are now ready to process messages from the servers. The cache ready message triggers the queued message replay process on the primary server. - -For an example that demonstrates `Cache.readyForEvents`, see [Sending the Cache Ready Message to the Server](sending-cache-ready-message.html#concept_C28D015FA85B4EE4B2F8D2DA5FCAFBFF). - -This figure shows the concurrent procedures that occur during the initialization process. The application begins operations immediately on the client (step 1), while the client's cache ready message (also step 1) triggers a series of queue operations on the cache servers (starting with step 2 on the primary server). At the same time, the client registers interest (step 2 on the client) and receives a response from the server. - -Message B2 applies to an entry in Region A, so the cache listener handles B2's event. Because B2 comes before the marker, the client does not apply the update to the cache. - -<a id="concept_38C027837216434CB5DEC84DF56B807E__fig_5A5566FB9EBE4A6D906E9D8FA687B4C5"></a> -<span class="figtitleprefix">Figure: </span> Initialization of a Reconnected Durable Client - -<img src="../common/images/7-Preserving_Data-2.gif" id="concept_38C027837216434CB5DEC84DF56B807E__image_1B3693DB90D041F193496BA24849D114" class="image" /> - -Only one region is shown for simplicity, but the messages in the queue could apply to multiple regions. Also, the figure omits the concurrent cache updates on the servers, which would normally be adding more messages to the client's message queue. http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/sending-cache-ready-message.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/sending-cache-ready-message.html.md.erb b/geode-docs/nativeclient/preserving-data/sending-cache-ready-message.html.md.erb deleted file mode 100644 index ed3355a..0000000 --- a/geode-docs/nativeclient/preserving-data/sending-cache-ready-message.html.md.erb +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Sending Cache Ready Messages to the Server ---- - -After a durable client connects and initializes its cache, regions, cache listeners, and any interest registration, it invokes `readyForEvents` to indicate to the servers that the client is ready to receive any messages accumulated for it. - -## Durable Client Cache Ready Notification (C++) - -The following example shows how to call `readyForEvents`. - -``` pre -//Send ready for event message to server(only for durable clients). -//Server will send queued events to client after receiving this. -cachePtr->readyForEvents(); -``` - -To keep the client from losing events, do not call this method until all regions and listeners are created. For more information, see [Reconnection](reconnection.html#concept_38C027837216434CB5DEC84DF56B807E). - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/sending-periodic-ack.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/sending-periodic-ack.html.md.erb b/geode-docs/nativeclient/preserving-data/sending-periodic-ack.html.md.erb deleted file mode 100644 index 2b33ab0..0000000 --- a/geode-docs/nativeclient/preserving-data/sending-periodic-ack.html.md.erb +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Sending Periodic Acknowledgment ---- - -Servers use periodic acknowledgment to reduce the likelihood of duplicate notifications, and to reduce resource usage. - -<a id="concept_868B8082463846DE9F35BBEA56105C82__section_D4375BCCF8A2426BA58073B9549B6F04"></a> -When redundancy is enabled for high availability and `redundancy-level` is set to 1 or higher, clients send (and servers expect) periodic acknowledgment messages at configurable intervals for notifications they have received. A periodic ack is not sent by the client if there are no unacknowledged notifications at the time. - -Use the following system properties in the `gfcpp.properties` file to configure periodic ack. - -<table> -<colgroup> -<col width="50%" /> -<col width="50%" /> -</colgroup> -<tbody> -<tr class="odd"> -<td><code class="ph codeph">notify-ack-interval</code></td> -<td><p>Minimum period between two consecutive acknowledgment messages sent from the client to the server. The default setting (in seconds) is 10.</p></td> -</tr> -<tr class="even"> -<td><code class="ph codeph">notify-dupcheck-life</code></td> -<td><p>Minimum time a client continues to track a notification source for duplicates when no new notifications arrive before expiring it. The default setting (in seconds) is 300.</p></td> -</tr> -</tbody> -</table> - -The Pool API also provides attributes to configure periodic ack and duplicate message tracking timeout. See `subscription-message-tracking-timeout` and `subscription-ack-interval` in the list of pool attributes under [Configuring Pools for Servers or Locators](../connection-pools/configuring-pools.html#configuring-pools). - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/preserving-data/using-queue-conflation.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/preserving-data/using-queue-conflation.html.md.erb b/geode-docs/nativeclient/preserving-data/using-queue-conflation.html.md.erb deleted file mode 100644 index 81b8ff5..0000000 --- a/geode-docs/nativeclient/preserving-data/using-queue-conflation.html.md.erb +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Enabling Queue Conflation to Improve Update Performance ---- - -Conflation of entry update messages can reduce the number of update messages a native client receives, thereby increasing performance. The native client receives only the most recent update for a particular entry key. - -Conflation is enabled for a cache server region, so all clients receiving updates for a particular region benefit from the conflation. To enable conflation, set the cache serverâs `enable-subscription-conflation` region attribute to `true`. This region attribute is `false` by default. - -The queue managment code conflates entry updates as part of the enqueue operation. If the previous enqueued item for that key is also an `update` operation, the queue management code removes that previously enqueued update, leaving only the latest update to be sent when event distribution occurs. For high availability, conflation also occurs for any secondary queues. - -Only entry `update` messages in a cache server region with `distributed-no-ack` scope are conflated. Region operations and entry operations other than updates are not conflated. - -For more information, see [Conflate the Server Subscription Queue](../../developing/events/conflate_server_subscription_queue.html). - -## <a id="concept_AEFA04AF9ABD42C0A37ED31806596D24__section_BE506A32A8E44073B197B03AC5232C01" class="no-quick-link"></a>Overriding Queue Conflation Per-Client - -Override conflation on a per-client basis by setting the conflate-events property in the native clientâs `gfcpp.properties` file. - -Valid settings are: - -- `server`. Uses the server settings. -- `true`. Conflates everything sent to the client. -- `false`. Does not conflate anything sent to the client. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/programming-examples/cpp-example.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/programming-examples/cpp-example.html.md.erb b/geode-docs/nativeclient/programming-examples/cpp-example.html.md.erb deleted file mode 100644 index 697cfa3..0000000 --- a/geode-docs/nativeclient/programming-examples/cpp-example.html.md.erb +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: API Programming Example â C++ ---- - -The next example uses the C++ API to implement a cache loader, which is generally used to retrieve data from an outside source. - -``` pre -CacheablePtr TestCacheLoader::load(const RegionPtr& region, - const CacheableKeyPtr& key, - const UserDataPtr& aCallbackArgument) -{ - m_bInvoked = true; - printf("CacheLoader.load : %s\n", printEvent(region, key, - aCallbackArgument).c_str()); - CacheablePtr value = NULLPTR; - try { - value = region->get(key, aCallbackArgument); - } catch(Exception& ex) { - fprintf(stderr, "Exception in TestCacheCallback::printEvent [%s]\n", ex.getMessage()); - } - if (value != NULLPTR) { - printf( "Loader found value: "); - std::string formatValue = printEntryValue(value); - printf( "%s\n",formatValue.c_str()); - } else { - printf( " Loader did not find a value"); - } - - return value; -} -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/programming-examples/csharp-example.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/programming-examples/csharp-example.html.md.erb b/geode-docs/nativeclient/programming-examples/csharp-example.html.md.erb deleted file mode 100644 index 92ce686..0000000 --- a/geode-docs/nativeclient/programming-examples/csharp-example.html.md.erb +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: API Programming Example â C\# ---- - -This C\# programming code in the next example demonstrates how to use two or more clients sharing a distributed region in a Geode cache. - -``` pre -using System; -using GemStone.GemFire.Cache; - -namespace GemStone.GemFire.Cache.QuickStart { - // The BasicOperations QuickStart example. - class BasicOperations { - static void Main(string[] args) { - try { - // Create a Cache. - CacheFactory cacheFactory = CacheFactory.CreateCacheFactory(null); - - Cache cache = cacheFactory.SetSubscriptionEnabled(true).Create(); - - Console.WriteLine("Created the Cache"); - - RegionFactory regionFactory = - cache.CreateRegionFactory(RegionShortcut.CACHING_PROXY); - - Region region = regionFactory.Create("exampleRegion"); - - Console.WriteLine("Created the Region Programmatically."); - - // Put an Entry (Key and Value pair) into the Region using the - // direct/shortcut method. - region.Put("Key1", "Value1"); - - Console.WriteLine("Put the first Entry into the Region"); - - // Put an Entry into the Region by manually creating a Key and - // a Value pair. - CacheableInt32 key = new CacheableInt32(123); - CacheableString value = new CacheableString("123"); - region.Put(key, value); - - Console.WriteLine("Put the second Entry into the Region"); - - if (IntPtr.Size == 8) { // Are we a 64 bit process? - Char ch = 'A'; - string text = new string(ch, 1024 * 1024); - for (int item = 0; item < (5 * 1024 /* 5 GB */); item++) { - region.LocalPut(item, text); - } - Console.WriteLine("Put over 4 GB data locally"); - } - // Get Entries back out of the Region. - IGFSerializable result1 = region.Get("Key1"); - - Console.WriteLine("Obtained the first Entry from the Region"); - - IGFSerializable result2 = region.Get(key); - - Console.WriteLine("Obtained the second Entry from the Region"); - - // Invalidate an Entry in the Region. - region.Invalidate("Key1"); - - Console.WriteLine("Invalidated the first Entry in the Region"); - - // Destroy an Entry in the Region. - region.Destroy(key); - - Console.WriteLine("Destroyed the second Entry in the Region"); - - // Close the GemFire Cache. - cache.Close(); - - Console.WriteLine("Closed the Cache"); - } - // An exception should not occur - catch (GemFireException gfex) { - Console.WriteLine("BasicOperations Exception: {0}", - gfex.Message); - } - } -} -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/programming-examples/native-client-region.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/programming-examples/native-client-region.html.md.erb b/geode-docs/nativeclient/programming-examples/native-client-region.html.md.erb deleted file mode 100644 index 6e15afd..0000000 --- a/geode-docs/nativeclient/programming-examples/native-client-region.html.md.erb +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: Declaring a Native Client Region ---- - -The following example shows how to declare a native client region in a `cache.xml` file. - -``` pre -<cache> - <region name = "root1" > - <region-attributes refid="CACHING_PROXY" pool-name="poolName1"/> - </region> - <region name = "root2" > - <region-attributes refid="PROXY" pool-name="poolName2"/> - </region> - <pool name="poolName1" subscription-enabled="true"> - <server host="localhost" port="40404" /> - </pool> - <pool name="poolName2" subscription-enabled="true"> - <server host="localhost" port="40404" /> - </pool> -</cache> -``` - -- The pool defines a list of cache servers that the native client region can communicate with. -- The *CACHING\_PROXY* setting causes the client region to cache data and to communicate with the servers. The *PROXY* setting causes the client region to communicate with the servers, but cache no data. -- The region *subscription-enabled* property, if `true` , indicates that the client should receive data updates when server data changes. -- Native clients do not specify cache loaders or writers, which are provided by the server. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/programming-examples/programming-examples.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/programming-examples/programming-examples.html.md.erb b/geode-docs/nativeclient/programming-examples/programming-examples.html.md.erb deleted file mode 100644 index 0e1446d..0000000 --- a/geode-docs/nativeclient/programming-examples/programming-examples.html.md.erb +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Programming Examples ---- - -This chapter provides a set of programming examples to help you understand the Geode native client API. - -- **[Declaring a Native Client Region](../../nativeclient/programming-examples/native-client-region.html)** - - The following example shows how to declare a native client region in a `cache.xml` file. - -- **[API Programming Example â C\#](../../nativeclient/programming-examples/csharp-example.html)** - - This C\# programming code in the next example demonstrates how to use two or more clients sharing a distributed region in a Geode cache. - -- **[API Programming Example â C++](../../nativeclient/programming-examples/cpp-example.html)** - -- **[Data Serialization Examples](../../nativeclient/programming-examples/serialization-overview.html)** - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/programming-examples/serialization-cpp.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/programming-examples/serialization-cpp.html.md.erb b/geode-docs/nativeclient/programming-examples/serialization-cpp.html.md.erb deleted file mode 100644 index 840dcb3..0000000 --- a/geode-docs/nativeclient/programming-examples/serialization-cpp.html.md.erb +++ /dev/null @@ -1,296 +0,0 @@ ---- -title: C++ Serialization Example ---- - -This C++ example implements an embedded object. - -``` pre -class User : public Serializable -{ - private: - std::string name; - int32_t userId; - ExampleObject *eo; - public: - User( std::string name, int32_t userId ) - : name( name ),userId( userId ) - { - eo = new ExampleObject(this->userId); - } - - ~User() { - if (eo != NULL) delete eo; - eo = NULL; - } - - User () { - name = ""; - userId = 0; - eo = new ExampleObject(userId); - } - - User( const char *strfmt, char delimeter ) { - std::string userId_str; - std::string sValue(strfmt); - std::string::size_type pos1 = sValue.find_first_of(delimeter); - std::string::size_type pos2; - if (pos1 == std::string::npos) { - userId_str = sValue; - name = sValue; - } else { - userId_str = sValue.substr(0, pos1); - pos2 = sValue.find(delimeter, pos1+1); - int len; - len = sValue.length()-pos1; - if (pos2==std::string::npos) { - } else { - len = pos2-pos1; - } - name = sValue.substr(pos1+1, len); - } - userId = (int32_t)atoi(userId_str.c_str()); - eo = new ExampleObject(userId_str); - } - - CacheableStringPtr toString() const { - CacheableStringPtr eo_str = eo->toString(); - char userId_str[128]; - sprintf(userId_str,"User: %d", userId); - std::string sValue = std::string(userId_str) + "," + name + "\n"; - sValue += std::string(eo_str->asChar()); - return CacheableString::create( sValue.c_str() ); - } - - int32_t getUserId( ) { - return userId; - } - - std::string getName( ) { - return name; - } - - ExampleObject *getEO() { - return eo; - } - - void setEO(ExampleObject *eObject) { - eo = eObject; - } - - // Add the following for the Serializable interface - // Our TypeFactoryMethod - - static Serializable* createInstance( ) { - return new User(std::string("gester"), 123); - } - - int32_t classId( ) const { - return 0x2d; // 45 - } - - void toData( DataOutput& output ) const { - output.writeASCII( name.c_str(), name.size() ); - output.writeInt( userId ); - eo->toData(output); - } - - uint32_t objectSize( ) const { - return ( sizeof(char) * ( name.size() + 1 ) ) + - sizeof(User) + eo->objectSize(); - } - - Serializable* fromData( DataInput& input ) { - char *readbuf; - input.readASCII( &readbuf ); - name = std::string(readbuf); - input.freeUTFMemory( readbuf ); - input.readInt( &userId ); - eo->fromData(input); - return this; - } -}; -``` - -This C++ example implements complex data types. - -``` pre -class ExampleObject -: public Serializable -{ - private: - double double_field; - float float_field; - long long_field; - int int_field; - short short_field; - std::string string_field; - std::vector<std::string> string_vector; - public: - ExampleObject() { - double_field = 0.0; - float_field = 0.0; - long_field = 0; - int_field = 0; - short_field = 0; - string_field = ""; - string_vector.clear(); - } - - ~ExampleObject() { - } - - ExampleObject(int id) { - char buf[64]; - sprintf(buf, "%d", id); - std::string sValue(buf); - int_field = id; - long_field = int_field; - short_field = int_field; - double_field = (double)int_field; - float_field = (float)int_field; - string_field = sValue; - string_vector.clear(); - for (int i=0; i<3; i++) { - string_vector.push_back(sValue); - } - } - - ExampleObject(std::string sValue) { - int_field = atoi(sValue.c_str()); - long_field = int_field; - short_field = int_field; - double_field = (double)int_field; - float_field = (float)int_field; - string_field = sValue; - string_vector.clear(); - for (int i=0; i<3; i++) { - string_vector.push_back(sValue); - } - } - - CacheableStringPtr toString() const { - char buf[1024]; - std::string sValue = "ExampleObject: "; - sprintf(buf,"%f(double),%f(double),%ld(long),%d(int),%d(short),", double_field,float_field,long_field,int_field,short_field); - sValue += std::string(buf) + string_field + "(string),"; - if (string_vector.size() >0) { - sValue += "["; - for (unsigned int i=0; i<string_vector.size(); i++) { - sValue += string_vector[i]; - if (i != string_vector.size()-1) { - sValue += ","; - } - } - sValue += "](string vector)"; - } - return CacheableString::create( sValue.c_str() ); - } - - double getDouble_field() { - return double_field; - } - - float getFloat_field() { - return float_field; - } - - long getLong_field() { - return long_field; - } - - int getInt_field() { - return int_field; - } - - short getShort_field() { - return short_field; - } - - std::string & getString_field() { - return string_field; - } - - std::vector<std::string> & getString_vector( ) { - return string_vector; - } - - // Add the following for the Serializable interface - // Our TypeFactoryMethod - - static Serializable* createInstance( ) { - return new ExampleObject(); - } - - int32_t classId( ) const - { - return 0x2e; // 46 - } - - bool operator== ( const Serializable& other ) const { - const ExampleObject& otherEO = static_cast<const ExampleObject&>( other ); - return ( 0 == strcmp( otherEO.toString()->asChar(), toString()->asChar() ) ); - } - - uint32_t hashcode( ) const { - return int_field; - } - - uint32_t objectSize( ) const - { - uint32_t objectSize = sizeof(ExampleObject); - objectSize += sizeof(char) * ( string_field.size() + 1 ); - size_t itemCount = string_vector.size(); - for( size_t idx = 0; idx < itemCount; idx++ ) { - // copy each string to the serialization buffer, including the null - // terminating character at the end of the string. - objectSize += sizeof(char) * ( string_vector[idx].size() + 1 ); - } - return objectSize; - } - - void toData( DataOutput& output ) const { - output.writeDouble( double_field ); - output.writeFloat( float_field ); - output.writeInt( (int64_t)long_field ); - output.writeInt( (int32_t)int_field ); - output.writeInt( (int16_t)short_field ); - output.writeASCII( string_field.c_str(), string_field.size()); - size_t itemCount = string_vector.size(); - output.writeInt( (int32_t) itemCount ); - for( size_t idx = 0; idx < itemCount; idx++ ) { - // copy each string to the serialization buffer, including the null - // terminating character at the end of the string. - output.writeASCII( string_vector[idx].c_str(), string_vector[idx].size() ); - } - } - - Serializable* fromData( DataInput& input ) - { - char *readbuf; - input.readDouble( &double_field ); - input.readFloat( &float_field ); - input.readInt( (int64_t *)(void *)&long_field ); - input.readInt( (int32_t *)(void *)&int_field ); - input.readInt( (int16_t *)(void *)&short_field ); - - int32_t itemCount = 0; - input.readASCII( &readbuf ); - string_field = std::string(readbuf); - input.freeUTFMemory( readbuf ); - - string_vector.clear(); - input.readInt( (int32_t*) &itemCount ); - for( int32_t idx = 0; idx < itemCount; idx++ ) { - // read from serialization buffer into a character array - input.readASCII( &readbuf ); - // and store in the history list of strings. - string_vector.push_back( readbuf ); - input.freeUTFMemory( readbuf ); - } - return this; - } -}; -typedef SharedPtr<ExampleObject> ExampleObjectPtr; -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/programming-examples/serialization-csharp.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/programming-examples/serialization-csharp.html.md.erb b/geode-docs/nativeclient/programming-examples/serialization-csharp.html.md.erb deleted file mode 100644 index 3d17a68..0000000 --- a/geode-docs/nativeclient/programming-examples/serialization-csharp.html.md.erb +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: C# Serialization Example ---- - -This C# .NET example shows how to implement a user-defined Serializable object. - -``` pre -class User : IGFSerializable -{ - private string m_name; - private int m_userId; - ExampleObject m_eo; - - public User(string name, int userId) - { - m_name = name; - m_userId = userId; - m_eo = new ExampleObject(); - } - - public User() - { - m_name = string.Empty; - m_userId = 0; - m_eo = new ExampleObject(); - } - - public int UserId - { - get - { - return m_userId; - } - - } - - public string Name - { - get - { - return m_name; - } - } - - public ExampleObject EO - { - get - { - return m_eo; - } - set - { - m_eo = value; - } - } - - public override string ToString() - { - return string.Format("User: {0}, {1}\n{2}", m_userId, m_name, - m_eo.ToString()); - } - - // Our TypeFactoryMethod - public static IGFSerializable CreateInstance() - { - return new User(); - } - -#region IGFSerializable Members - - public UInt32 ClassId() - { - get - { - return 45; // must match Java - } - } - - public IGFSerializable FromData(DataInput input) - { - m_name = input.ReadUTF(); - m_userId = input.ReadInt32(); - m_eo.FromData(input); - return this; - } - - public void ToData(DataOutput output) - { - output.writeUTF(m_name); - output.writeInt32(m_userId); - eo.ToData(output); - } - -#endregion -} -``` - -
