http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/object-lifetimes.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/object-lifetimes.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/object-lifetimes.html.md.erb deleted file mode 100644 index b3acf2d..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/object-lifetimes.html.md.erb +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Object Lifetimes ---- - -The .NET API provides a managed set of assemblies for the C++ API. The underlying C++ object will stay in memory until the .NET object is garbage-collected. - -The underlying C++ API employs reference counting using smart pointers for most classes. This means that all API operations with those objects return a reference to the underlying object and not a copy. Consequently, the underlying object will not be freed as long as the .NET application holds a reference to an object. In other words, the underlying object will stay in memory until the .NET object is garbage-collected. As long as a reference to an object is alive, the artifacts it maintains will also be alive. - -For example, as long as a `Region` object is not garbage-collected, then the destructor of the C++ native persistence manager (if any) for the region is not invoked. - -In the C++ API, the references to an object are reduced when the object goes out of scope for stack allocation, or is deleted explicitly for heap allocation. The object is destroyed when its reference count reaches zero. In the .NET API, the references are reduced when the object is garbage-collected or is explicitly disposed with the .NET `using` statement. - -Because a reference to the object is returned, any change to the object also immediately changes the object as stored internally. For example, if an object is put into the cache using `Region.Put`, a reference of the object is stored in the internal structures. If you modify the object, the internal object also changes. However, it is not distributed to other members of the distributed system until another `Region.Put` is done. - -To find out if a class is reference counted, look at the online API documentation for the class. If the class is wrapped by `UMWrap` or `SBWrap`, the class is reference counted. - -These are examples of classes that are reference counted: - -- `Cache` -- `CacheStatistics` -- `DistributedSystem` -- `Properties` -- `RegionAttributes` -- `AttributesMutator` -- `RegionEntry` -- `Region` -- `EntryEvent` -- `RegionEvent` - -These are examples of classes that are not reference counted: - -- `AttributesFactory` -- `DataInput` -- `DataOutput` -- `SystemProperties` - -
http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/other-apis.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/other-apis.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/other-apis.html.md.erb deleted file mode 100644 index 89c34e4..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/other-apis.html.md.erb +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: Property Collections and Logging APIs ---- - -This section describes classes for property collections and logging. - -- **Properties** **class**. Provides a collection of properties, each of which is a key/value pair. Each key is a string, and the value can be a string or an integer. -- **Log class**. Defines methods available to clients that need to write a log message to their Geode system shared log file. Any attempt to use an instance after its connection is disconnected throws a **NotConnectedException**. For any logged message the log file contains: - - The log level of the message. - - The time the message was logged. - - The ID of the connection and thread that logged the message. - - The message itself, possibly with an exception including its stack trace. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/primary-apis-cache-generic.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/primary-apis-cache-generic.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/primary-apis-cache-generic.html.md.erb deleted file mode 100644 index fa3bbf6..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/primary-apis-cache-generic.html.md.erb +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Primary APIs ---- - -These are the main APIs within `GemStone::GemFire::Cache::Generic` used for cache, region, and data entry management in Geode .NET. For detailed information about the APIs, see the .NET API documentation included in the product or available online. - -**Note:** -Declarative configuration via XML of application plug-ins such as cache listener, cache writer, cache loader and partition resolver is not supported when clients are operated in the new .NET Generic API. - -- **[Cache APIs](../../nativeclient/dotnet-caching-api/cache-apis.html)** - - This section describes the `CacheFactory` and `Cache` classes. - -- **[Region and Entry APIs](../../nativeclient/dotnet-caching-api/region-entry-apis.html)** - - This section describes classes for working with Geode regions and region entries. - -- **[Data Serialization APIs](../../nativeclient/dotnet-caching-api/data-serialization-apis.html)** - - Use either `IPdxSerializable` or `IGFSerializable` for each region. Do not mix the two. - -- **[Event Handling APIs](../../nativeclient/dotnet-caching-api/event-handling-apis.html)** - - Code your event handlers to do minimal work before returning control to Geode. - -- **[Property Collections and Logging APIs](../../nativeclient/dotnet-caching-api/other-apis.html)** - - This section describes classes for property collections and logging. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/private-assembly.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/private-assembly.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/private-assembly.html.md.erb deleted file mode 100644 index e3aa34e..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/private-assembly.html.md.erb +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: Using GemStone.GemFire.Cache.dll As a Private Assembly ---- - -To access `GemStone.GemFire.Cache.dll` as a private assembly, you need to specify a `.config` file for your application. - -The file needs to be the same name as your application, with a `.config` suffix. For example, the `.config` file for `main.exe` would be `main.exe.config`. The two files must reside in the same directory. - -Follow these steps to create a `.config` file: - -1. Copy `%GFCPP%/docs/default.exe.config` to the appropriate location. -2. Rename `default.exe.config` to the name of your application. -3. Change the `href` attribute of the `CodeBase` element to point to your `GemStone.GemFire.Cache.dll` file. Any of three path types â http, relative, or absolute â will work. - -## A Sample .config File - -The following example shows an excerpt of a `.config` file. The `PublicKeyToken` value is only an example, and the codebase version value is not set correctly. See `%GFCPP%/docs/default.exe.config` for an actual example for this release. - -``` pre -<configuration> - <runtime> - <assemblyBinding - xmlns="urn:schemas-microsoft-com:asm.v1"> - <dependentAssembly> - <assemblyIdentity name="GemStone.GemFire.Cache" - publicKeyToken="126e6338d9f55e0c" - culture="neutral" /> - <codeBase version="0.0.0.0" - href="../../bin/GemStone.GemFire.Cache.dll"/> - </dependentAssembly> - </assemblyBinding> - </runtime> -</configuration> -``` - -**Note:** -If the `.config` file contain errors, no warning or error messages are issued. The application runs as if no `.config` file is present. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/problem-scenarios.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/problem-scenarios.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/problem-scenarios.html.md.erb deleted file mode 100644 index 4d7c4ec..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/problem-scenarios.html.md.erb +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Problem Scenarios ---- - -These scenarios describe processes and implementations that should be avoided when using `AppDomains`. - - -## <a id="concept_025AAAF8896C4F4CB4530EE9CEEF4BAE__section_FFC3E18AD8F042DA9EFB42852242AAE0" class="no-quick-link"></a>Using Application Callbacks - -**Scenario:** A .NET thread loads the Geode DLL in application domain `AD1`. This thread may have access to the other domains in the application if code access security allows it. This thread can then call `AppDomain.CreateInstance` to create a callback object ( `ICacheListener`, `ICacheLoader`, or `ICacheWriter`) in another domain called `AD2`. If the callback object is marshaled by reference, the callback is executed in the domain where it is created (`AD2`). The thread that loads the Geode DLL in domain `AD1` runs the callback methods in the second domain, `AD2`. An exception is thrown when the callback method is invoked because the native code that invokes the callback is not allowed to cross the `AppDomain` boundary. - -**Resolution:** When an application creates and unloads application domains it should ensure that the application domain where the Geode .NET DLL is loaded is the same domain where the application callback and `IGFSerializable` objects are created. - -## <a id="concept_025AAAF8896C4F4CB4530EE9CEEF4BAE__section_9FEC4666F4FD467AA57AD70943703F00" class="no-quick-link"></a>Loading an Application DLL in Multiple AppDomains - -**Scenario:** the application loads the Geode DLL in one application domain, then reloads the Geode DLL in another application domain (with or without unloading the previous `AppDomain` ). The callbacks, as well as other interface implementations, like `IPdxSerializable` and `IGFSerializable`, throw exceptions because the native C++ code does not know about `AppDomains` and is loaded only once in the initial `AppDomain`. - -**Resolution:** The application should always use the first `AppDomain` to load the Geode DLL, or it should not load the Geode DLL multiple times. - -## <a id="concept_025AAAF8896C4F4CB4530EE9CEEF4BAE__section_646373554C764DD3A919A906A5F05EE9" class="no-quick-link"></a>Native Client inside IIS - -**Scenario:** When you deploy more than one web application inside an Internet Information Service (IIS), the IIS creates an appdomain subprocess for each web application in the single process, but the native client C++ cache instance remains a singleton in the process. Because of this, you can run into conflicts between cache creation and closure by the different appdomains. For example, if one appdomain calls `cache.close`, it closes the cache for the entire process. Any further cache access operations by the other appdomains return cache closed exceptions. - -**Resolution:** `Cache create`/`close` provides reference counting of `Cache` `create` and `close`. Each process can use the counter to make sure it creates the `Cache` once and closes it once. To enable this, set the Geode system property, `appdomain-enabled` to true . http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/programming-ipdxinstance.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/programming-ipdxinstance.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/programming-ipdxinstance.html.md.erb deleted file mode 100644 index 3e6ff68..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/programming-ipdxinstance.html.md.erb +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Program Your Application to Use IPdxInstance ---- - -An `IPdxInstance` is a lightweight wrapper around PDX serialized bytes. It provides applications with run-time access to fields of a PDX serialized object. - -You can configure your cache to return an `IPdxInstance` when a PDX serialized object is deserialized instead of deserializing the object to a domain class. You can then program your application code that reads your entries to handle `IPdxInstances` fetched from the cache. - -**Note:** -This option applies only to entry retrieval that you explicitly code using methods like `EntryEvent.getNewValue` and `Region.get`, as you do inside functions or in cache listener code. This does not apply to querying because the query engine retrieves the entries and handles object access for you. - -**Note:** -`IPdxInstance` overrides any custom implementation you might have coded for your object's `equals` and `hashcode` methods. - -**Procedure** - -1. In the `cache.xml` file of the server member where entry fetches are run, set the `<pdx>` read-serialized attribute to true. - - Data is not necessarily accessed on the member that you have coded for it. For example, if a client application runs a function on a server, the actual data access is done on the server, so you set read-serialized to true on the server. - - For example: - - ``` pre - // Cache configuration setting PDX read behavior - <cache> - <pdx read-serialized="true" /> - ... </cache> - ``` - -2. Write the application code that fetches data from the cache to handle a `IPdxInstance`. If you are sure you will only retrieve `IPdxInstances` from the cache, you can code only for that. In many cases, a `IPdxInstance` or a domain object may be returned from your cache entry retrieval operation, so you should check the object type and handle each possible type. - - See [Creating an IPdxInstance with IPdxInstanceFactory](using-ipdxinstancefactory.html#concept_8FA31D0D022146CE8DE2197006507AFF__example_89B7EDD2BE27423BA0CAB9B0270348B5) for an example of this. - -If you configure your cache to allow PDX serialized reads, cache fetches return the data in the form it is found. If the object is not serialized, the fetch returns the domain object. If the object is serialized, the fetch returns the `PdxInstance` for the object. - -**Note:** -If you are using `IPdxInstances`, you cannot use delta propagation to apply changes to PDX serialized objects. - -For example, in client/server applications that are programmed and configured to handle all data activity from the client, PDX serialized reads done on the server side will always return the `IPdxInstance`. This is because all of data is serialized for transfer from the client and you are not performing any server-side activities that would deserialize the objects in the server cache. - -In mixed situations, such as where a server cache is populated from client operations and also from data loads done on the server side, fetches done on the server can return a mix of `IPdxInstances` and domain objects. - -When fetching data in a cache with PDX serialized reads enabled, the safest approach is to code to handle both types, receiving an Object from the fetch operation, checking the type and casting as appropriate. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/region-entry-apis.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/region-entry-apis.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/region-entry-apis.html.md.erb deleted file mode 100644 index c8cd483..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/region-entry-apis.html.md.erb +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Region and Entry APIs ---- - -This section describes classes for working with Geode regions and region entries. - -- **RegionFactory class**. Creates a `Region` instance based on the provided configuration. -- **IRegion class**. Provides functions for managing regions and cached data. The `Region` interface implements the generic .NET `IDictionary` interface. In the Geode APIs, `IRegion` implements `IDictionary` and `Region` inherits `IRegion`, giving you access to the full range of .NET `Generic` collection functions. Use the functions in this class to perform the following actions: - - Retrieve information about the region, such as its parent region and region attribute objects. - - Invalidate or destroy the region. - - Add, update, invalidate, and remove region entries. - - Determine, individually or as entire sets, the region's entry keys, entry values, and `RegionEntry` objects. -- **RegionEntry class**. Contains the key and value for the entry, and provides all non-distributed entry operations. The operations of this object are not distributed and do not affect statistics. -- **RegionShortcut class**. Holds `enum` definitions for the most common region configurations. Start your region configuration with a shortcut setting in the region attribute, `refid`. Then customize further using the `RegionAttributes`. -- **RegionAttributes class**. Holds all attribute values for a region and provides functions for retrieving all attribute settings. This class can only be modified by the `AttributesFactory` class before region creation, and the `AttributesMutator` class after region creation. -- **AttributesMutator class**. Allows modification of an existing region's attributes for application plug-ins and expiration actions. Each region has an `AttributesMutator` instance. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/registering-the-type.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/registering-the-type.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/registering-the-type.html.md.erb deleted file mode 100644 index 098bb6d..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/registering-the-type.html.md.erb +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Register the Type ---- - -To use the `BankAccount` type, you must register it with the type system. Then, when an incoming stream contains a `BankAccount`, it can be manufactured from the associated `TypeFactoryMethod.` - -``` pre -Serializable.RegisterType(BankAccount.CreateInstance); -``` - -Typically, you would register the type before creating the system. - -## <a id="concept_FFFB0AAA131E46D09065F910EFF218CB__section_1B68CDA7392E45CAA413362F42CCF829" class="no-quick-link"></a>Using ClassId - -A `ClassId` is an integer that returns the `ClassId` of the instance being serialized. The `ClassId` is used by deserialization to determine what instance type to create and deserialize into. - -## <a id="concept_FFFB0AAA131E46D09065F910EFF218CB__section_8A63DBA039744DCCB6840A7F1F5734DA" class="no-quick-link"></a>Using DSFID - -A `DSFID` is an integer that returns the data serialization fixed ID type. `DSFID` is used to determine what instance type to create and deserialize into. `DSFID` should not be overridden by custom implementations, and it is reserved only for built-in serializable types. - -## <a id="concept_FFFB0AAA131E46D09065F910EFF218CB__section_A02B5E61D03B4B0893DFF3D21F2346F9" class="no-quick-link"></a>Using Custom Key Types - -If your application uses its own key types that are too complex to easily force into string, you can probably improve performance by using a custom type and implementing `HashCode` and `Equals` functions. For example, if you have hybrid data types such as floating point numbers, you can implement your own type that encapsulates the floating point number. Comparing floating point numbers in this way provides greater performance than comparing a string representation of the floating point numbers, with such noticeable improvements as faster cache access and smaller payloads. - -See [Serialization in Native Client Mode with a Java Server](../cpp-caching-api/serialization_using_serializable.html#concept_696AB5206C3E45898CC1A24CDD93D003__section_AFB685227E4048BF9FB4FD7C55AED274) for information about implementing key types for a native client that is used with a Java cache server. - -To extend a type that implements `IPdxSerializable` or `IGFSerializable` for your key, override and implement the `HashCode` and `Equals` methods in the key as needed. http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/removing-entry.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/removing-entry.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/removing-entry.html.md.erb deleted file mode 100644 index f8b6853..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/removing-entry.html.md.erb +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Removing an Entry ---- - -The standard `Region::Remove` API removes the entry with specified key and provides a user-defined parameter object to any `CacheWriter` or `CacheListener` invoked in the process. - -The `Remove` call not only removes the value, but also the key and entry from this region. The remove operation is propagated to the Geode cache server that the native client is connected to. If the destroy operation fails due to an exception on the server (for example, a `CacheServerException` or security exception), then the local entry is still removed. - -The `Remove` operation updates `CacheStatistics::LastAccessedTime`, `CacheStatistics::HitCount`, and `CacheStatistics::MissCount` for this region and the entry. - -The `Remove` API returns true if the entry (key, value) has been removed or false if the entry (key, value) has not been removed. - -## Bulk Remove Operations Using removeAll - -You can use the `Region::removeAll` API to remove all entries for a colleciton of specified keys from the region. The effect of this call is equivalent to that of calling `destroy` on this region once for each key in the specified collection. If an entry does not exist, then that key is skipped. Note that an `EntryNotFoundException` is not thrown. - -The `RemoveAll` operation updates `CacheStatistics::LastAccessedTime`, `CacheStatistics::HitCount`, and `CacheStatistics::MissCount` for this region and the entries that are removed. - -The `RemoveAll` API also supports providing a callback argument to any cache loaders or cache writers that are invoked in the operation. See the Region online API documentation for more information about using `RemoveAll`. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/resolving-the-error.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/resolving-the-error.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/resolving-the-error.html.md.erb deleted file mode 100644 index 65cc0cc..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/resolving-the-error.html.md.erb +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Resolving the Error ---- - -Each computer where the common language runtime is installed has a machine-wide code cache called the Global Assembly Cache (GAC). The global assembly cache stores assemblies specifically designated to be shared by several applications on the computer. - -As a general guideline, keep assembly dependencies private, and locate assemblies in the application directory unless sharing an assembly is explicitly required. Share assemblies by installing them into the global assembly cache only when necessary. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/serializable-types.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/serializable-types.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/serializable-types.html.md.erb deleted file mode 100644 index 45826fc..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/serializable-types.html.md.erb +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Generic and Custom Serializable Types ---- - -All built-in generics are automatically registered at initialization. You have a couple of options for complex key types. - -If your application uses more complex key types that you want to make more accessible or easier to handle, you can derive a new class from `IGFSerializable`. Another option is for the application to do its own object serialization using `Byte[]` or a custom type. - -## <a id="concept_5D520C87F65B48AFA4240615190B0150__section_DA3BCFFFCB974C65BEE953DF3FAA8442" class="no-quick-link"></a>Blobs - -If you have data that is best handled as a blob, such as structs that do not contain pointers, use a `Byte[]` or, if you need something more complex than `Byte[]`, implement a custom type using either `IPdxSerializable` or `IGFSerializable`. - -## <a id="concept_5D520C87F65B48AFA4240615190B0150__section_D49865F1CF5F467A9FFAD244D990F3F5" class="no-quick-link"></a>Object Graphs - -If you have a graph of objects in which each node can be serializable, the parent node calls `DataOutput.WriteObject` to delegate the serialization responsibility to its child nodes. Similarly, your application calls `DataInput.ReadObject` to deserialize the object graph. - -**Note:** -The Geode `IGFSerializable` interface does not support object graphs with multiple references to the same object. If your application uses these types of circular graphs, you must address this design concern explicitly. - -For more information, see the online API documentation for `DataOutput` and `DataInput`. http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/serialize-using-igfserializable.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/serialize-using-igfserializable.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/serialize-using-igfserializable.html.md.erb deleted file mode 100644 index dde87e8..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/serialize-using-igfserializable.html.md.erb +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Serialize with the Geode IGFSerializable Interface ---- - -The .NET `IGFSerializable` interface provides fast and compact data serialization. - -- **[Generic and Custom Serializable Types](serializable-types.html)** - - All built-in generics are automatically registered at initialization. You have a couple of options for complex key types. - -- **[How Serialization Works with IGFSerializable](how-igfserializable-works.html)** - - When your application puts an object into the cache for distribution, Geode serializes the data by taking these steps. - -- **[Implement the IGFSerializable Interface](implementing-igfserializable.html)** - - To store your own data types in the cache, you implement the Geode `IGFSerializable` interface. - -- **[Register the Type](registering-the-type.html)** - - To use the `BankAccount` type, you must register it with the type system. Then, when an incoming stream contains a `BankAccount`, it can be manufactured from the associated `TypeFactoryMethod.` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/serialize-using-ipdxserializable.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/serialize-using-ipdxserializable.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/serialize-using-ipdxserializable.html.md.erb deleted file mode 100644 index b582a77..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/serialize-using-ipdxserializable.html.md.erb +++ /dev/null @@ -1,103 +0,0 @@ ---- -title: Serialize Using the GemFire IPdxSerializable Interface ---- - -Use this procedure to program your domain object for PDX serialization using the `IPdxSerializable` Interface. When you write objects using PDX serialization, they are distributed to the server tier in PDX serialized form. When you run queries against the objects on the servers, only the fields you specify are deserialized. - -**Procedure** - -1. In your domain class, implement `GemStone::GemFire::Cache::Generic::IPdxSerializable`. Example: - - ``` pre - using GemStone.GemFire.Cache.Generic; - ... - public class PortfolioPdx : IPdxSerializable - ``` - -2. If your domain class does not have a zero-arg constructor, create one for it. - - If you also use PDX serialization in Java for the object, serialize the object in the same way for each language. Serialize the same fields in the same order and mark the same identify fields. - -3. Program the `IPdxSerializable ToData` function to serialize your object as required by your application. - 1. Write your domain class's standard. NET data fields using the `IPdxWriter` write methods. GemFire automatically provides `IPdxWriter` to the `ToData` function for `IPdxSerializable` objects. - 2. Call the `ToData markIdentifyField` function for each field GemFire should use to identify your object. This is used to compare objects for operations like `DISTINCT` queries. The `markIdentifyField` call must come after the associated field write methods. - - Example: - - ``` pre - // object fields - private int m_id; - private string m_pkid; - private PositionPdx m_position1; - private PositionPdx m_position2; - private Hashtable m_positions; - private string m_type; - private string m_status; - private string[] m_names; - private byte[] m_newVal; - private DateTime m_creationDate; - private byte[] m_arrayZeroSize; - private byte[] m_arrayNull; - // ToData - public void ToData(IPdxWriter writer) - { - writer.WriteInt("id", m_id) - //identity field - .MarkIdentityField("id") - .WriteString("pkid", m_pkid) - .WriteObject("position1", m_position1) - .WriteObject("position2", m_position2) - .WriteObject("positions", m_positions) - .WriteString("type", m_type) - .WriteString("status", m_status) - .WriteStringArray("names", m_names) - .WriteByteArray("newVal", m_newVal) - .WriteDate("creationDate", m_creationDate) - .WriteByteArray("arrayNull", m_arrayNull) - .WriteByteArray("arrayZeroSize", m_arrayZeroSize); - } - ``` - -4. Program `IPdxSerializable FromData` to read your data fields from the serialized form into the object's fields using the `IPdxReader` read methods. GemFire automatically provides `IPdxReader` to the `FromData` function for `IPdxSerializable` objects. - - Use the same names as you did in `ToData` and call the read operations in the same order as you called the write operations in your `ToData` implementation. - - Example: - - ``` pre - public void FromData(IPdxReader reader) - { - m_id = reader.ReadInt("id"); - - bool isIdentity = reader.IsIdentityField("id"); - - if (isIdentity == false) - throw new IllegalStateException("Portfolio id is identity field"); - - bool isId = reader.HasField("id"); - - if (isId == false) - throw new IllegalStateException("Portfolio id field not found"); - - bool isNotId = reader.HasField("ID"); - - if (isNotId == true) - throw new IllegalStateException("Portfolio isNotId field found"); - - m_pkid = reader.ReadString("pkid"); - m_position1 = (PositionPdx)reader.ReadObject("position1"); - m_position2 = (PositionPdx)reader.ReadObject("position2"); - m_positions = (Hashtable)reader.ReadObject("positions"); - m_type = reader.ReadString("type"); - m_status = reader.ReadString("status"); - m_names = reader.ReadStringArray("names"); - m_newVal = reader.ReadByteArray("newVal"); - m_creationDate = reader.ReadDate("creationDate"); - m_arrayNull = reader.ReadByteArray("arrayNull"); - m_arrayZeroSize = reader.ReadByteArray("arrayZeroSize"); - } - ``` - -5. Optionally, program your domain object's equals and hashcode methods. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/serializing-domain-objects.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/serializing-domain-objects.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/serializing-domain-objects.html.md.erb deleted file mode 100644 index c25b28f..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/serializing-domain-objects.html.md.erb +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: Serialize Your Domain Objects with IPdxSerializer ---- - -For domain objects that you cannot or do not want to modify, use the `IPdxSerializer` class to serialize and deserialize the object's fields. - -You use one `IPdxSerializer` implementation for the entire cache, programming it for all of the domain objects that you handle in this way. This way you do not have to implement the `IPdxSerializable` interface for each domain class. - -With `IPdxSerializer`, you leave your domain object as-is and handle the serialization and deserialization in the separate serializer. You register the serializer in your cache PDX configuration. Then program the serializer to handle all of the domain objects you need. - -If you write your own `IPdxSerializer` and you also use the `ReflectionBasedAutoSerializer`, then the `IPdxSerializer` needs to own the `ReflectionBasedAutoSerializer` and delegate to it. A cache can only have a single `IPdxSerializer` instance. - -**Note:** -The `IPdxSerializer` `toData` and `fromData` methods differ from those for `IPdxSerializable`. They have different parameters and results. - -To register an `IPdxSerializer`, you can use the following code. Note that you can only register the `IPdxSerializer` in the application code. It cannot be configured declaratively in `cache.xml`. - -Example: - -``` pre -using GemStone.GemFire.Cache.Generic; -... -// Register a PdxSerializer to serialize -// domain objects using PDX serialization - -Serializable.RegisterPdxSerializer(new MyPdxSerializer()); -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/simple-csharp-example.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/simple-csharp-example.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/simple-csharp-example.html.md.erb deleted file mode 100644 index d9f9949..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/simple-csharp-example.html.md.erb +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: A Simple C# Example ---- - -An example shows how to connect to Geode, create a cache and region, put and get keys and values, and disconnect. - -## Simple C\# Code - -``` pre -class BasicOperations -{ - public static void Main(string[] args) - { - try - { - // 1. Create a cache - CacheFactory cacheFactory = CacheFactory.CreateCacheFactory(); - Cache cache = cacheFactory.Create(); - - // 2. Create default region attributes using region factory - RegionFactory regionFactory = - cache.CreateRegionFactory(RegionShortcut.CACHING_PROXY); - - // 3. Create a region - IRegion<int, string> region = - regionFactory.Create<int, string>("exampleRegion"); - - // 4. Put some entries - region[111] = "Value1"; - region[123] = "123"; - - // 5. Get the entries - string result1 = region[111]; - string result2 = region[123]; - - // 6. Close cache - cache.Close(); - } - } -} -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/troubleshooting-dotnet-applications.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/troubleshooting-dotnet-applications.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/troubleshooting-dotnet-applications.html.md.erb deleted file mode 100644 index 74dec75..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/troubleshooting-dotnet-applications.html.md.erb +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Troubleshooting .NET Applications ---- - -The .NET Framework does not find managed DLLs using the conventional `PATH` environment variable. In order for your assembly to find and load a managed DLL, it must either be loaded as a private assembly using `assemblyBinding`, or it must be installed into the Global Assembly Cache (GAC). - -The GAC utility must be run on every machine that runs the .NET code. - -If an assembly attempts to load the `GemStone.GemFire.Cache.dll` without meeting this requirement, you receive this `System.IO.FileNotFoundException`: - -``` pre -{{ - -Unhandled Exception: System.IO.FileNotFoundException: Could not load file -or assembly 'GemStone.GemFire.Cache, Version=8.0.0.0, Culture=neutral, -PublicKeyToken= 126e6338d9f55e0c' or one of its dependencies. The system -cannot find the file specified. -File name: 'GemStone.GemFire.Cache, Version=8.0.0.0, Culture=neutral, -PublicKeyT oken=126e6338d9f55e0c' -at HierarchicalClient.Main() - -}} -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/dotnet-caching-api/using-ipdxinstancefactory.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/dotnet-caching-api/using-ipdxinstancefactory.html.md.erb b/geode-docs/nativeclient/dotnet-caching-api/using-ipdxinstancefactory.html.md.erb deleted file mode 100644 index 04c1297..0000000 --- a/geode-docs/nativeclient/dotnet-caching-api/using-ipdxinstancefactory.html.md.erb +++ /dev/null @@ -1,111 +0,0 @@ ---- -title: Use the IPdxInstanceFactory to Create IPdxInstances ---- - -You can use the `IPdxInstanceFactory` to create an `IPdxInstance` from raw data when the domain class is not available on the server. - -This option can be useful when you need an instance of a domain class for plug-in code such as a function or a loader. If you have the raw data for the domain object (the class name and each field's type and data), then you can explicitly create a `IPdxInstance`. The `IPdxInstanceFactory` is very similar to the `IPdxWriter` except that after writing each field, you need to call the create method which returns the created `IPdxInstance.` - -## Creating an IPdxInstance with IPdxInstanceFactory - -``` pre -/* - * The PdxInstance QuickStart Example. - * This example takes the following steps: - * - * This example shows IPdxInstanceFactory and IPdxInstance usage. - * - * 1. Create a Cache. - * 2. Creates the PdxInstanceFactory for Person class. - * 3. Then creates instance of PdxInstance - * 4. It does put. - * 5. Then it does get and access it fields. - * 6. Close the Cache. - * - */ - // Use standard namespaces - using System; - using System.Reflection; - // Use the GemFire namespace - using GemStone.GemFire.Cache.Generic; - namespace GemStone.GemFire.Cache.Generic.QuickStart - { - public class Person - { - private string name; - //this is the only field used on server to create hashcode and use in equals method - [PdxIdentityField] - private int id; - private int age; - public Person() { } - public Person(string name, int id, int age) - { - this.name = name; - this.id = id; - this.age = age; - } - #region Public Properties - public string Name - { - get { return name; } - } - public int ID - { - get { return id; } - } - public int Age - { - get { return age; } - } - #endregion - } - // The PdxRemoteQuery QuickStart example. -class PdxInstance - { - static void Main(string[] args) - { - try { - CacheFactory cacheFactory = CacheFactory.CreateCacheFactory(null); - Console.WriteLine("Connected to the Distributed System"); - // Create a Cache with the "clientPdxRemoteQuery.xml" Cache XML file. - // Set SetPdxReadSerialized to true to access PdxInstance - Cache cache = cacheFactory.Set("cache-xml-file", "XMLs/clientPdxInstance.xml").Create(); - Console.WriteLine("Created the Cache"); - // Get the example Region from the Cache which is declared in the Cache XML file. - IRegion<string, IPdxInstance> region = cache.GetRegion<string, IPdxInstance>("Person"); - Console.WriteLine("Obtained the Region from the Cache"); - Person p = new Person("Jack", 7, 21); - //PdxInstanceFactory for Person class - IPdxInstanceFactory pif = cache.CreatePdxInstanceFactory("Person"); - pif.WriteString("name", p.Name); - pif.WriteInt("id", p.ID); - pif.MarkIdentityField("id"); - pif.WriteInt("age", p.Age); - IPdxInstance pdxInstance = pif.Create(); - Console.WriteLine("Created PdxInstance for Person class"); - region["Key1"] = pdxInstance; - Console.WriteLine("Populated PdxInstance Object"); - IPdxInstance retPdxInstance = region["Key1"]; - if((int)retPdxInstance.GetField("id") == p.ID - && (int)retPdxInstance.GetField("age") == p.Age - && (string)retPdxInstance.GetField("name") == p.Name - && retPdxInstance.IsIdentityField("id") == true) - Console.WriteLine("PdxInstance returns all fields value expected"); - else - Console.WriteLine("PdxInstance doesn't returns all fields value expected"); - // Close the Cache. - cache.Close(); - Console.WriteLine("Closed the Cache"); - } - // An exception should not occur - catch (GemFireException gfex) - { - Console.WriteLine("PdxSerializer Exception: {0}", - gfex.Message); - } - } - } -} -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/function-execution/data-aware-function-execution.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/function-execution/data-aware-function-execution.html.md.erb b/geode-docs/nativeclient/function-execution/data-aware-function-execution.html.md.erb deleted file mode 100644 index e0d2004..0000000 --- a/geode-docs/nativeclient/function-execution/data-aware-function-execution.html.md.erb +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Understanding Data-Aware Function Routing ---- - -Achieving linear scalability is predicated upon being able to horizontally partition the application data such that concurrent operations by distributed applications can be done independently across partitions. - -In other words, if the application requirements for transactions can be restricted to a single partition, and all data required for the transaction can be colocated to a single server member or a small subset of server members, then true parallelism can be achieved by vectoring the concurrent accessors to the ever-growing number of partitions. - -Most scalable enterprise applications grow in data volume, where the number of data items managed rather than the size of individual items grows over time. If the above logic holds (especially true for OLTP class applications), then we can derive sizable benefits by routing the data-dependent application code to the fabric member hosting the data. This routing of application code to the data of interest is called data-aware function routing, or behavior routing. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/function-execution/executing-functions.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/function-execution/executing-functions.html.md.erb b/geode-docs/nativeclient/function-execution/executing-functions.html.md.erb deleted file mode 100644 index f19939b..0000000 --- a/geode-docs/nativeclient/function-execution/executing-functions.html.md.erb +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Executing Functions ---- - -Using the Geode function execution service, you can execute application functions on a single server member, in parallel on a subset of server members, or in parallel on all server members of a distributed system. - -In these procedures, it is assumed that you have defined your client and server regions, and that you have coded and configured your servers to run your functions. In [Function Execution](../../developing/function_exec/chapter_overview.html), see the function execution information for the server side. - -- **[Running the Function](../../nativeclient/function-execution/running-function.html)** - - In this section you create an `Execution` object and use its methods to define and run the function. To run a function with high availability, you call `getResult` from the results collector returned from the `execute` method. - -- **[Programming to Get Function Results](../../nativeclient/function-execution/handling-function-results.html)** - - Geode provides a default result collector. If you need special results handling, code a custom `ResultsCollector` implementation to replace the provided default. Use the `Execution::withCollector` method to define your custom collector. - -- **[Solutions and Use Cases](../../nativeclient/function-execution/solutions-use-cases.html)** - - The function execution service provides solutions for various application use cases. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/function-execution/function-execution.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/function-execution/function-execution.html.md.erb b/geode-docs/nativeclient/function-execution/function-execution.html.md.erb deleted file mode 100644 index 57dd024..0000000 --- a/geode-docs/nativeclient/function-execution/function-execution.html.md.erb +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Function Execution ---- - -*Function Execution* describes how you can execute application functions to achieve linear scalability. It explains how function execution works and lists specific use cases. - -**Note:** -Function execution can be used only along with the pool functionality. For more information about the pool API, see [Using Connection Pools](../connection-pools/connection-pools.html#using-connection-pools). Only C++ versions of Function Execution API interfaces, classes, and methods (like `FunctionService::onRegion`) are shown in text. The code examples show C++ and C\#. - -- **[Understanding Data-Aware Function Routing](../../nativeclient/function-execution/data-aware-function-execution.html)** - - Achieving linear scalability is predicated upon being able to horizontally partition the application data such that concurrent operations by distributed applications can be done independently across partitions. - -- **[How Functions Execute](../../nativeclient/function-execution/how-functions-execute.html)** - - This section discusses the basic function execution process, how highly available functions execute after a failure, and the execution scenarios for data-dependent and data-independent functions. - -- **[Executing Functions](../../nativeclient/function-execution/executing-functions.html)** - - Using the Geode function execution service, you can execute application functions on a single server member, in parallel on a subset of server members, or in parallel on all server members of a distributed system. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/function-execution/handling-function-results.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/function-execution/handling-function-results.html.md.erb b/geode-docs/nativeclient/function-execution/handling-function-results.html.md.erb deleted file mode 100644 index 8891009..0000000 --- a/geode-docs/nativeclient/function-execution/handling-function-results.html.md.erb +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Programming to Get Function Results ---- - -Geode provides a default result collector. If you need special results handling, code a custom `ResultsCollector` implementation to replace the provided default. Use the `Execution::withCollector` method to define your custom collector. - -**Note:** -This section applies only to functions that return results. - -To program your client to get the results from a function, use the result collector returned from the function execution, like this: - -``` pre -ResultCollectorPtr rc = FunctionService::onRegion(region) - ->withArgs(args) - ->withFilter(keySet) - ->withCollector(new MyCustomResultCollector()) - .execute(Function); -CacheableVectorPtr functionResult = rc.getResult(); -``` - -The `getResult` methods of the Geode default result collector block until all results are received, then return the full result set. - -You can handle the results in a custom manner if you wish. To do this: - -1. Write a class that extends `ResultCollector` and code the methods to handle the results as you need. The methods are of two types: one handles data and information from Geode and populates the results set, while the other returns the compiled results to the calling application: - - 1. `addResult` is called by Geode when results arrive from the `Function` methods. Use `addResult` to add a single result to the ResultCollector. - 2. `endResults` is called by Geode to signal the end of all results from the function execution. - 3. `getResult` is available to your executing application (the one that calls `Execution.execute`) to retrieve the results. This may block until all results are available. - 4. `clearResults` is called by Geode to clear partial results from the results collector. This is used only for highly available `onRegion` functions where the calling application waits for the results. If the call fails, before Geode retries the execution, it calls `clearResults` to ready the instance for a clean set of results. - -2. Use the `Execution` object in your executing member to call `withCollector`, passing your custom collector, as shown in the example above. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/function-execution/how-functions-execute.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/function-execution/how-functions-execute.html.md.erb b/geode-docs/nativeclient/function-execution/how-functions-execute.html.md.erb deleted file mode 100644 index d3bb4be..0000000 --- a/geode-docs/nativeclient/function-execution/how-functions-execute.html.md.erb +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: How Functions Execute ---- - -This section discusses the basic function execution process, how highly available functions execute after a failure, and the execution scenarios for data-dependent and data-independent functions. - -## <a id="how-functions-execute__section_B3311A9E6A9243BB8403BFD3B488B840" class="no-quick-link"></a>How Functions Execute - -1. The calling client application runs the `execute` method on the `Execution` object. The object must already be registered on the servers. -2. The function is invoked on all servers where it needs to run. The locations are determined by the `FunctionService on*` method calls, region configuration, and any filters. -3. If the function has results, the result is returned to the `AddResult` method call in a `ResultCollector` object. -4. The client collects results using the result collector `getResult`. - -## <a id="how-functions-execute__section_08C66E4B3D934ADC8587DF1E3766C9FD" class="no-quick-link"></a>How Highly Available Functions Execute after a Failure - -If a failure occurs in function execution, the error is returned to the calling application. You can code for high availability for `onRegion` functions that return a result, so the function is automatically retried. For information on setting this up on the server side, see [Executing a Function in Apache Geode](../../developing/function_exec/function_execution.html). To use a highly available function, the client must call the results collector `getResult` method. When an execution error occurs or a member crashes while executing, the system does the following: - -1. Waits for all calls to return. -2. Sets a boolean indicating a reexecution is being done. -3. Calls the result collectorâs `clearResults` method. -4. Executes the function. - -The system retries the execution up to the number specified in the server poolâs `retryAttempts` setting. If the function continues to fail, the final exception is returned to the `getResult` method. - -## <a id="how-functions-execute__section_CD9A1A997259413EAB4E2A31E773EF3D" class="no-quick-link"></a>Data-Independent Function Execution - -The figure shows the sequence of events for a data-independent function executed against all available servers. - -<a id="how-functions-execute__fig_542AF21D578C4203B0E412B79AAFCB2B"></a> - -<span class="figtitleprefix">Figure: </span>Data-Independent Function Invoked from a Client - -<img src="../common/images/data-indep-func-from-client.gif" alt="Data-Independent Function Invoked on All Servers" id="how-functions-execute__image_E0558B648AC0408AA8EBA1B20BBDA6E8" class="image" /> - -## <a id="how-functions-execute__section_2B8EF74570294EDA9468303E6ABF1589" class="no-quick-link"></a>Data-Dependent Function Execution - -The figure shows a data-dependent function run by a client. The specified region is connected to the server system, so the function automatically goes there to run against all servers holding data for the region. - -<a id="how-functions-execute__fig_AB2806066EBD4A9A818C1CB96969AAD7"></a> - -<span class="figtitleprefix">Figure: </span>Data-Dependent Function Invoked From a Client - -<img src="../common/images/data-dep-func-from-client.gif" alt="Data-Dependent Function Invoked from a Client" id="how-functions-execute__image_2FC4D817034841748BA05E2805D0BC21" class="image" /> - -This shows the same data-dependent function with the added specification of a set of keys on which to run. Servers that don't hold any of the keys are left out of the function execution. - -<a id="how-functions-execute__fig_BAD8AB0EC37C4EC1AC78FB47D071AACC"></a> - -<span class="figtitleprefix">Figure: </span>Data-Dependent Function with Filter Invoked from a Client - -<img src="../common/images/data-dep-func-with-filter.gif" alt="Data-Dependent Function with Filter Invoked From a Client" id="how-functions-execute__image_E2C4F2E946204ED6999504E720EA5825" class="image" /> - -This scenario demonstrates the steps in a call to a highly available function. The call fails the first time on one of the participating servers and is successfully run a second time on all servers. - -<a id="how-functions-execute__fig_8178E71A5AD747C794A336C86BE313B8"></a> - -<span class="figtitleprefix">Figure: </span>Highly Available Data-Dependent Function with Failure on First Executions - -<img src="../common/images/ha-data-dep-func.gif" alt="Highly Available Data Dependent Function with Failure on First Execution" id="how-functions-execute__image_79E33270ADD147F780E5E20A03D9F3C6" class="image" /> - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/function-execution/running-function.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/function-execution/running-function.html.md.erb b/geode-docs/nativeclient/function-execution/running-function.html.md.erb deleted file mode 100644 index fa5e1ce..0000000 --- a/geode-docs/nativeclient/function-execution/running-function.html.md.erb +++ /dev/null @@ -1,122 +0,0 @@ ---- -title: Running the Function ---- - -In this section you create an `Execution` object and use its methods to define and run the function. To run a function with high availability, you call `getResult` from the results collector returned from the `execute` method. - -## <a id="running-function__section_8BC7F999141A40E389B8DC276EAB9F7E" class="no-quick-link"></a>Configuring and Running a Function - -You specify the members that run the function and, optionally, the data set over which the functions run. - -- **Servers**. Execute the function in a single server or a set of servers, specified by the server pool. To specify data sets for this type of function, pass arguments in to the function. -- **Data set**. Specify a region and possibly a set of keys on which to run. - -In every client where you want to execute the function and process the results: - -1. Use one of the `FunctionService on*` methods to create an `Execution` object. The `on*` methods, `onRegion`, `onServer` and `onServers`, define the highest level where the function is run. If you use `onRegion` you can further narrow your run scope by setting key filters. The function run using `onRegion` is a data dependent function â the others are data-independent functions. - - You can run a data dependent function against custom partitioned and colocated partitioned regions. From the client, provide the appropriate key sets to the function call. - -2. Use the `Execution` object as needed for additional function configuration. You can: - - Provide a set of data keys to `withFilter` to narrow the execution scope. This works only for `onRegion Execution` objects. - - Provide function arguments to `withArgs`. - - Define a custom `ResultCollector` to `withCollector`. See [Programming to Get Function Results](handling-function-results.html#handling-function-results). - -3. Call the `Execution` object execute method to run the function. -4. To run a function with high availability, call `getResult` from the results collector returned from `execute`. Calling a highly available function without using `getResult` disables the high availability functionality. - -## Running a Function on a Region (C++) - -``` pre -regPtr0 = initRegion(); -ExecutionPtr exc = FunctionService::onRegion(regPtr0); -CacheableVectorPtr routingObj = CacheableVector::create(); -char buf[128]; -bool getResult = true; - -sprintf(buf, "VALUE--%d", 10); -CacheablePtr value(CacheableString::create(buf)); - -sprintf(buf, "KEY--%d", 100); -CacheableKeyPtr key = CacheableKey::create(buf); -regPtr0->put(key, value); - -sprintf(buf, "KEY--%d", 100); -CacheableKeyPtr key1 = CacheableKey::create(buf); -routingObj->push_back(key1); - -CacheablePtr args = routingObj; -CacheableVectorPtr executeFunctionResult = exc->withFilter(routingObj)-> - withArgs(args)->execute(func)->getResult(); -``` - -## Running a Function on a Server Pool (C++) - -``` pre -pptr = PoolManager::find(poolName); -ExecutionPtr exc = FunctionService::onServer(cache); -CacheableVectorPtr routingObj = CacheableVector::create(); -char buf[128]; -bool getResult = true; -sprintf(buf, "VALUE--%d", 10); -CacheablePtr value(CacheableString::create(buf)); - -sprintf(buf, "KEY--%d", 100); -CacheableKeyPtr key = CacheableKey::create(buf); -regPtr0->put(key, value); - -sprintf(buf, "KEY--%d", 100); -CacheableKeyPtr key1 = CacheableKey::create(buf); -routingObj->push_back(key1); - -CacheablePtr args = routingObj; -CacheableVectorPtr executeFunctionResult = -exc->withArgs(args)->execute(func)->getResult(); -``` - -## Running a Function on a Region (C\# .NET) - -``` pre -IRegion<string, string> fregion = - regionFactory.Create<string, string>("exampleRegion"); -for (int i = 0; i < 34; i++) -{ - fregion.Put("KEY--" + i, "VALUE--" + i, null); -} - -object[] routingObj = new object[17]; -int j = 0; -for (int i = 0; i < 34; i++) -{ - if (i % 2 == 0) continue; - routingObj[j] = "KEY--" + i; - j++; -} -object args0 = true; -Boolean getResult = true; -// data dependent function execution -- get function with result -Execution<object> exc = - Generic.FunctionService.OnRegion<string, string, object>(fregion); -Generic.IResultCollector rc = - exc.WithArgs((IGFSerializable)args0).WithFilter( - (IGFSerializable[])routingObj).Execute(getFuncName); -object[] executeFunctionResult = rc.GetResult(); -``` - -## Running a Function on a Server Pool (C\# .NET) - -``` pre -exc = Generic.FunctionService.OnServer<object>(cache); -List<object> args1 = new List<object>(); -for (int i = 0; i < routingObj.Length; i++) -{ - Console.WriteLine("routingObj[{0}]={1}.", i, (routingObj[i] as string)); - args1.Add(routingObj[i]); -} -rc = exc.WithArgs((IGFSerializable)args1).Execute(getFuncIName); -executeFunctionResult = rc.GetResult(); -Console.WriteLine("on one server: result count= {0}.", - executeFunctionResult.Length); -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/function-execution/solutions-use-cases.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/function-execution/solutions-use-cases.html.md.erb b/geode-docs/nativeclient/function-execution/solutions-use-cases.html.md.erb deleted file mode 100644 index 364d53d..0000000 --- a/geode-docs/nativeclient/function-execution/solutions-use-cases.html.md.erb +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: Solutions and Use Cases ---- - -The function execution service provides solutions for various application use cases. - -- An application that executes a server-side transaction or makes data updates using the Geode distributed locking service. -- An application that initializes some of its components once on each server, which might be used later by executed functions. -- Initialization and startup of a third-party service, such as a messaging service. -- Any arbitrary aggregation operation that requires iteration over local data sets that can be done more efficiently through a single call to the cache server. -- Any kind of external resource provisioning that can be done by executing a function on a server. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/gfcpp.properties/chapter_overview.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/gfcpp.properties/chapter_overview.html.md.erb b/geode-docs/nativeclient/gfcpp.properties/chapter_overview.html.md.erb deleted file mode 100644 index 56782fc..0000000 --- a/geode-docs/nativeclient/gfcpp.properties/chapter_overview.html.md.erb +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: gfcpp.properties Example File ---- - -Use the gfcpp.properties file to configure distributed system connections for the Apache Geode native client. - -The following example shows the format of a gfcpp.properties file. The first two attributes in this example should be set by programmers during application development, while other attributes are set on-site during system integration. The properties and their default settings that can be set in this file are described in detail in [Attributes in gfcpp.properties](../setting-properties/attributes-gfcpp.html#attributes-gfcpp). - -## gfcpp.properties File Format - -``` pre -#Tue Feb 14 17:24:02 PDT 2006 -log-level=info -cache-xml-file=./cache.xml -stacktrace-enabled=true -``` - -- **[Using the Default Sample File](../../nativeclient/gfcpp.properties/default_sample_file.html)** - - A sample gfcpp.properties file is included with the Apache Geode native client installation in the `productDir/defaultSystem` directory. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/gfcpp.properties/default_sample_file.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/gfcpp.properties/default_sample_file.html.md.erb b/geode-docs/nativeclient/gfcpp.properties/default_sample_file.html.md.erb deleted file mode 100644 index 15b828b..0000000 --- a/geode-docs/nativeclient/gfcpp.properties/default_sample_file.html.md.erb +++ /dev/null @@ -1,104 +0,0 @@ ---- -title: Using the Default Sample File ---- - -A sample gfcpp.properties file is included with the Apache Geode native client installation in the `productDir/defaultSystem` directory. - -To use this file: - -1. Copy the file to the directory where you start the application. -2. Uncomment the lines you need and edit the settings as shown in this example: - - ``` pre - cache-xml-file=test.xml - ``` - -3. Start the application. - -## Default gfcpp.properties File - -``` pre -# Default C++ distributed system properties -# Copy to current directory and uncomment to override defaults. -# -## Debugging support, enables stacktraces in gemfire::Exception. -# -# The default is false, uncomment to enable stacktraces in exceptions. -#stacktrace-enabled=true -#crash-dump-enabled=true -# -# -## Cache region configurtion -# -#cache-xml-file=cache.xml -# -## Log file config -# -#log-file=gemfire_cpp.log -#log-level=config -# zero indicates use no limit. -#log-file-size-limit=0 -# zero indicates use no limit. -#log-disk-space-limit=0 -# -## Statistics values -# -# the rate is in seconds. -#statistic-sample-rate=1 -#statistic-sampling-enabled=true -#statistic-archive-file=statArchive.gfs -# zero indicates use no limit. -#archive-file-size-limit=0 -# zero indicates use no limit. -#archive-disk-space-limit=0 -#enable-time-statistics=false -# -## Heap based eviction configuration -# -# maximum amount of memory used by the cache for all regions, 0 disables this feature -#heap-lru-limit=0 -# percentage over heap-lru-limit when LRU will be called. -#heap-lru-delta=10 -# -## Durable client support -# -#durable-client-id= -#durable-timeout=300 -# -## SSL socket support -# -#ssl-enabled=false -#ssl-keystore= -#ssl-truststore= -# -## .NET AppDomain support -# -#appdomain-enabled=false -# -## Misc -# -#conflate-events=server -#disable-shuffling-of-endpoints=false -#grid-client=false -#max-fe-threads= -#max-socket-buffer-size=66560 -# the units are in seconds. -#connect-timeout=59 -#notify-ack-interval=10 -#notify-dupcheck-life=300 -#ping-interval=10 -#redundancy-monitor-interval=10 -#auto-ready-for-events=true -# -## module name of the initializer pointing to sample -## implementation from templates/security -#security-client-auth-library=securityImpl -## static method name of the library mentioned above -#security-client-auth-factory=createUserPasswordAuthInitInstance -## credential for Dummy Authenticator configured in server. -## note: security-password property will be inserted by the initializer -## mentioned in the above property. -#security-username=root -``` - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/gfcpp.properties/gfcpp.properties_search_path.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/gfcpp.properties/gfcpp.properties_search_path.html.md.erb b/geode-docs/nativeclient/gfcpp.properties/gfcpp.properties_search_path.html.md.erb deleted file mode 100644 index f6e2b97..0000000 --- a/geode-docs/nativeclient/gfcpp.properties/gfcpp.properties_search_path.html.md.erb +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Search Path for Multiple gfcpp.properties Files ---- - -The native client and cache server processes first look for their properties file in the `productDir/defaultSystem` directory, then in the working directory. - -Any properties set in the working directory override settings in the `defaultSystem/gfcpp.properties` file. - -If you are running multiple processes on one machine, you can configure the `gfcpp.properties` file in the `defaultSystem` directory as a shared file that all processes can find. If a few processes need a slightly different configuration, you can put individual `gfcpp.properties` files in their home directories to override specific properties. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/gfcpp.properties/overriding_gfcpp.properties.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/gfcpp.properties/overriding_gfcpp.properties.html.md.erb b/geode-docs/nativeclient/gfcpp.properties/overriding_gfcpp.properties.html.md.erb deleted file mode 100644 index 3303cdb..0000000 --- a/geode-docs/nativeclient/gfcpp.properties/overriding_gfcpp.properties.html.md.erb +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Overriding gfcpp.properties Settings ---- - -Application developers have the option of configuring system attributes programmatically, rather than using the `gfcpp.properties` file. - -Attributes set programmatically override any matching attribute settings in the `gfcpp.properties` file, but additional attributes not set programmatically will be configured using the settings in `gfcpp.properties`. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/glossary.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/glossary.html.md.erb b/geode-docs/nativeclient/glossary.html.md.erb deleted file mode 100644 index 94eae02..0000000 --- a/geode-docs/nativeclient/glossary.html.md.erb +++ /dev/null @@ -1,213 +0,0 @@ ---- -title: Glossary ---- - -This glossary defines terms used in the documentation. - -## API - -Application Programming Interface. Geode provides APIs to cached data for C++ and .NET applications. - -## application program - -A program designed to perform a specific function directly for the user or, in some cases, for another application program. Geode applications use the Geode application programming interfaces (APIs) to modify cached data. - -## cache - -A cache created by an application or cache server process. For the process, its cache is the point of access to all caching features and the only view of the cache that is available. Cache creation requires membership in the distributed system. See also [local cache](#glossary_local_cache) and [remote cache](#nc_glossary_remote_cache). - -## cache configuration file - -An XML file that declares the initial configuration of a cache, commonly named `cache.xml`. C++ and .NET applications can configure the cache additionally through the Geode programming APIs. - -## cache listener - -User-implemented plug-in for receiving and handling region entry events. A region's cache listener is called after an entry in the local cache is modified. - -## <a id="nc_glossary_cache_loader" class="no-quick-link"></a>cache loader - -User-implemented plug-in for loading data into a region. A region's cache loader is used to load data that is requested of the region but is not available in the distributed system. For a distributed region, the loader that is used can be in a different cache from the one where the data-request operation originated. See also [cache writer](#nc_glossary_cache_writer) and [netSearch](#nc_glossary_netSearch). - -## cache server - -A long-running, configurable caching process, generally used to serve cached data to the applications. Usually, cache servers are configured to operate as servers in a client-server typology and their regions are configured to be replicates. See also [server](#nc_glossary_server). - -## <a id="nc_glossary_cache_writer" class="no-quick-link"></a>cache writer - -User-implemented plug-in intended for synchronizing the cache with an outside data source. A region's cache writer is a synchronous listener to cache data events. The cache writer has the ability to abort a data modification. See also [cache loader](#nc_glossary_cache_loader). - -## caching enabled - -Specifies whether data is cached in the region. Geode gives you the option of running applications without entry caching. For example, you can configure a distributed system as a simple messaging service. - -## client - -In a client-server topology, clients can connect to cache servers, create new regions on the cache server, and store data in the cache server region. Clients can also connect to existing regions on a cache server and do directed gets and puts on the cache server. Clients do not track membership information about other clients, nor do they share information with other clients. - -## concurrency level - -An estimate of the number of threads expected to concurrently modify values in the region. The actual concurrency may vary; this value is used to optimize the allocation of system resources. - -## connection - -What an application uses to access a Geode distributed system. An application can connect to a Geode system by calling the `DistributedSystem::connect` function with the appropriate parameter settings. An application must connect to a distributed system to gain access to Geode functionality. - -## destroy - -Remove an entry from a region or remove a region from a cache. - -## <a id="nc_glossary_disk_policy" class="no-quick-link"></a>disk policy - -Determines whether LRU entries exceeding the entries limit for a caching region are destroyed or written to disk. - -## <a id="nc_glossary_distributed_scope" class="no-quick-link"></a>distributed scope - -Enables a region to automatically send entry value updates to remote caches and incorporate updates received from remote caches. The scope identifies whether distribution operations must wait for acknowledgement from other caches before continuing. A distributed region's **cache loader** and **cache writer** (defined in the local cache) can be invoked for operations originating in remote caches. - -## distributed system - -One or more Geode system members that have been configured to communicate with each other, forming a single, logical system. Also used for the object that is instantiated to create the connection between the distributed system members. - -## DTD - -Document Type Definition. A language that describes the contents of a Standard Generalized Markup Language (SGML) document. The DTD is also used with XML. The DTD definitions can be embedded within an XML document or in a separate file. - -## <a id="nc_glossary_entry" class="no-quick-link"></a>entry - -A data object in a region. A region entry consists of a key and a value. The value is either null (invalid) or an object. A region entry knows what region it is in. See also [region data](#nc_glossary_region_data), [entry key](#nc_glossary_entry_key), and [entry value](#nc_glosssary_entry_value). - -## <a id="nc_glossary_entry_key" class="no-quick-link"></a>entry key - -The unique identifier for an entry in a region. - -## <a id="nc_glosssary_entry_value" class="no-quick-link"></a>entry value - -The data contained in an entry. - -## expiration - -A cached object expires when its time-to-live or idle timeout counters are exhausted. A region has one set of expiration attributes for itself and one set for all region entries. - -## <a id="nc_glossary_expiration_action" class="no-quick-link"></a>expiration action - -The action to be taken when a cached object expires. The expiration action specifies whether the object is to be invalidated or destroyed, and whether the action is to be performed only in the local cache or throughout the distributed system. A destroyed object is completely removed from the cache. A region is invalidated by invalidating all entries contained in the region. An entry is invalidated by having its value marked as invalid. - -Expiration attributes are set at the region level for the region and at the entry level for entries. See also [idle timeout](#nc_glossary_idle_timeout) and [time-to-live](#nc_glossary_time-to-live). - -## factory method - -An interface for creating an object which at creation time can let its subclasses decide which class to instantiate. The factory method helps instantiate the appropriate subclass by creating the correct object from a group of related classes. - -## <a id="nc_glossary_idle_timeout" class="no-quick-link"></a>idle timeout - -The amount of time a region or region entry may remain in the cache unaccessed before being expired. Access to an entry includes any `get` operation and any operation that resets the entry's time-to-live counter. Region access includes any operation that resets an entry idle timeout, and any operation that resets the region's time-to-live. - -Idle timeout attributes are set at the region level for the region and at the entry level for entries. See also [time-to-live](#nc_glossary_time-to-live) and [expiration action](#nc_glossary_expiration_action). - -## interest list - -A mechanism that allows a region to maintain information about receivers for a particular key-value pair in the region, and send out updates only to those nodes. Interest lists are particularly useful when you expect a large number of updates on a key as part of the entry life cycle. - -## invalid - -The state of an object when the cache holding it does not have the current value of the object. - -## invalidate - -Remove only the value of an entry in a cache, not the entry itself. - -## listener - -An event handler. The listener registers its interest in one or more events and is notified when the events occur. - -## load factor - -A region attribute that sets initial parameters on the underlying hashmap used for storing region entries. - -## <a id="nc_glossary_local_cache" class="no-quick-link"></a>local cache - -The part of the distributed cache that is resident in the current process. This term is used to differentiate the cache where a specific operation is being performed from other caches in the distributed system. See also [remote cache](#nc_glossary_remote_cache). - -## <a id="nc_glossary_local_scope" class="no-quick-link"></a>local scope - -Enables a region to hold a private data set that is not visible to other caches. See also [scope](#nc_glossary_scope). - -## LRU - -Least Recently Used. Refers to a region entry or entries most eligible for eviction due to lack of interest by client applications. - -## LRU entries limit - -A region attribute that sets the maximum number of entries to hold in a caching region. When the capacity of the caching region is exceeded, LRU is used to evict entries. - -## membership - -Applications and cache servers connect to a Geode distributed system by invoking the static function `DistributedSystem::connect`. Through this connection, the application gains access to the APIs for distributed data caches. When a C++ or .NET application connects to a distributed system, it specifies the system it is connecting to by indicating the communication protocol and address to use to find other system members. - -## <a id="nc_glossary_netSearch" class="no-quick-link"></a>netSearch - -The method used by Geode to search remote caches for a data entry that is not found in the local cache region. This operates only on distributed regions. - -## <a id="nc_glossary_overflows" class="no-quick-link"></a>overflows - -An eviction option that causes the values of LRU entries to be moved to disk when the region reaches capacity. See [disk policy](#nc_glossary_disk_policy). - -## persistence manager - -The persistence manager manages the memory-to-disk and disk-to-memory actions for LRU entries. See [overflows](#nc_glossary_overflows). - -## region - -A logical grouping of data within a cache. Regions are used to store data entries (see [entry](#nc_glossary_entry)). Each region has a set of attributes governing activities such as expiration, distribution, data loading, events, and eviction control. - -## region attributes - -The class of attributes governing the creation, location, distribution, and management of a region and its entries. - -## <a id="nc_glossary_region_data" class="no-quick-link"></a>region data - -All of the entries directly contained in the region. - -## region entry - -See [entry](#nc_glossary_entry). - -## <a id="nc_glossary_remote_cache" class="no-quick-link"></a>remote cache - -Any part of the distributed cache that is resident in a process other than the current one. If an application or cache server does not have a data entry in the region in its local cache, it can do a `netSearch` in an attempt to retrieve the entry from the region in a remote cache. See also [local cache](#nc_glossary_local_cache). - -## <a id="nc_glossary_scope" class="no-quick-link"></a>scope - -Region attribute. Identifies whether a region keeps its entries private or automatically sends entry value updates to remote caches and incorporates updates received from remote caches. The scope also identifies whether distribution operations must wait for acknowledgement from other caches before continuing. See also [distributed scope](#nc_glossary_distributed_scope) and [local scope](#nc_glossary_local_scope). - -## serialization - -The process of converting an object graph to a stream of bytes. - -## <a id="nc_glossary_server" class="no-quick-link"></a>server - -In a client-server topology, the server manages membership and allows remote operations. The server maintains membership information for its clients in the distributed system, along with information about peer applications and other servers in the system. See also **cache server**. - -## system member - -A process that has established a connection to a distributed system. - -## <a id="nc_glossary_time-to-live" class="no-quick-link"></a>time-to-live - -The amount of time a region or region entry may remain in the cache without being modified before being expired. Entry modification includes creation, update, and removal. Region modification includes creation, update, or removal of the region or any of its entries. - -Time-to-live attributes are set at the region level for the region, and at the entry level for entries. See also **idle timeout** and **expiration action**. - -## XML - -EXtensible Markup Language. An open standard for describing data from the W3C, XML is a markup language similar to HTML. Both are designed to describe and transform data, but where HTML uses predefined tags, XML allows tags to be defined inside the XML document itself. Using XML, virtually any data item can be identified. The XML programmer creates and implements data-appropriate tags whose syntax is defined in a DTD file or an XSD (XML schema definition.) - -## <a id="glossary__section_B65D71221D6F4F02B829EE4DB12FFCAB" class="no-quick-link"></a>XML schema definition - -The definition of the structure, content, and semantics used in an XML document. The definition can be used to verify that each item of content in a document adheres to the specification of the element in which the content is placed. The XML schema is a superset of DTD. Unlike DTD, XML schemas are written in XML syntax, which, although more verbose than DTD, are more descriptive and can have stronger typing. Files containing XML schema definitions generally have the XSD extension. - -## XSD - -See XML schema definition. - - http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/381d0faa/geode-docs/nativeclient/introduction/developing-linux.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/nativeclient/introduction/developing-linux.html.md.erb b/geode-docs/nativeclient/introduction/developing-linux.html.md.erb deleted file mode 100644 index 8d7424b..0000000 --- a/geode-docs/nativeclient/introduction/developing-linux.html.md.erb +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: Developing C++ Programs on Linux ---- - -This section describes how to build and run a native client application on Linux. - -**Note:** When compiling external projects or applications that are used or referenced by the Geode native client, make sure that you compile them for the same target architecture as your native client installation. For example, if you installed the 64-bit (x86) version of the native client, compile your external projects for 64-bit (x86) architecture. - -## <a id="developing-linux__section_4AD6E18611AE42E9942C77DF91347768" class="no-quick-link"></a>Step 1. Set Environment Variables - -Set the native client environment variables on each Linux 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-linux__section_EFE9D42B05B44F2F958054224BCC5F76" class="no-quick-link"></a>Step 2. Compile C++ Clients and Dynamically Link Them to the GemFire Library - -On Linux, the `g++` compiler is supported. To build and link a C++ client to GemFire on Linux, the compilation command line must include the arguments listed in the following table. - -<a id="developing-linux__compiler-arguments-linux"></a> - -| Argument | Explanation | -|--------------------|----------------------------------------------------------| -| `-D_REENTRANT` | Required to compile Linux programs in a thread-safe way. | -| `-m32` or `-m64` | Enables 32-bit or 64-bit compilation. | -| `-I$GFCPP/include` | Specifies the native client `include` directory. | - - -The following table lists the linker switches that must be present on the command line when dynamically linking to the GemFire library. - -<a id="developing-linux__table_216E9E87FBB44E39BE26388317F3ACE4"></a> - -| Argument | Explanation | -|---------------------|----------------------------------------------------------------------------------------------------| -| `-rpath $GFCPP/lib` | Tells the linker to look in `$GFCPP/lib` for libraries on which the native client library depends. | -| `-L$GFCPP/lib` | Tells the linker where to find the named libraries. | -| `-o durableclient` | Tells the linker to output an object file named 'durableclient'. | -| `-lgfcppcache` | Links the native client C++ cache library to the compiled executable. | - - -The following examples compile and link the `$GFCPP/SampleCode/quickstart/cpp/DurableClient.cpp` client to the `durableclient` output file. - -**Compiling and Dynamically Linking on Linux for 32-bit** - -``` pre -g++ \ --D_REENTRANT \ --03 \ --Wall \ --m32 \ --I$GFCPP/include \ -cpp/DurableClient.cpp \ -cpp/plugins/DurableCacheListener.cpp \ --o cpp/DurableClient \ --L$GFCPP/lib \ --Wl,-rpath,$GFCPP/lib \ --lgfcppcache -``` - -**Compiling and Dynamically Linking on Linux for 64-bit** - -``` pre -g++ \ --D_REENTRANT \ --03 \ --Wall \ --m64 \ --I$GFCPP/include \ -cpp/DurableClient.cpp \ -cpp/plugins/DurableCacheListener.cpp \ --o cpp/DurableClient \ --L$GFCPP/lib \ --Wl,-rpath,$GFCPP/lib \ --lgfcppcache -``` - -## <a id="developing-linux__section_60711FB51F0546D48C0BE84C1EB1D379" class="no-quick-link"></a>Step 3. Make Sure the Native Client Library Can Be Loaded - -When the C++ application is dynamically linked to the native client library, the library must be dynamically loadable. - -To ensure 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.
