# sprint-2 - added documentation.
Project: http://git-wip-us.apache.org/repos/asf/incubator-ignite/repo Commit: http://git-wip-us.apache.org/repos/asf/incubator-ignite/commit/3e65882a Tree: http://git-wip-us.apache.org/repos/asf/incubator-ignite/tree/3e65882a Diff: http://git-wip-us.apache.org/repos/asf/incubator-ignite/diff/3e65882a Branch: refs/heads/ignite-141 Commit: 3e65882a387697a50692cc424aa38456e7158b97 Parents: 8d15d8f Author: Dmitiry Setrakyan <dsetrak...@gridgain.com> Authored: Fri Mar 6 19:09:19 2015 -0800 Committer: Dmitiry Setrakyan <dsetrak...@gridgain.com> Committed: Fri Mar 6 19:09:19 2015 -0800 ---------------------------------------------------------------------- wiki/documentation/basic-concepts/async-support.md | 1 - .../basic-concepts/getting-started.md | 1 - .../basic-concepts/ignite-life-cycel.md | 1 - wiki/documentation/basic-concepts/maven-setup.md | 1 - .../documentation/basic-concepts/what-is-ignite.md | 1 - .../basic-concepts/zero-deployment.md | 1 - wiki/documentation/clustering/aws-config.md | 1 - wiki/documentation/clustering/cluster-config.md | 1 - wiki/documentation/clustering/cluster-groups.md | 1 - wiki/documentation/clustering/cluster.md | 1 - wiki/documentation/clustering/leader-election.md | 1 - wiki/documentation/clustering/network-config.md | 1 - wiki/documentation/clustering/node-local-map.md | 1 - wiki/documentation/compute-grid/checkpointing.md | 1 - .../compute-grid/collocate-compute-and-data.md | 1 - wiki/documentation/compute-grid/compute-grid.md | 1 - wiki/documentation/compute-grid/compute-tasks.md | 1 - .../compute-grid/distributed-closures.md | 1 - .../documentation/compute-grid/executor-service.md | 1 - wiki/documentation/compute-grid/fault-tolerance.md | 1 - wiki/documentation/compute-grid/job-scheduling.md | 1 - wiki/documentation/compute-grid/load-balancing.md | 1 - .../data-grid/affinity-collocation.md | 1 - .../data-grid/automatic-db-integration.md | 1 - wiki/documentation/data-grid/cache-modes.md | 1 - wiki/documentation/data-grid/cache-queries.md | 1 - wiki/documentation/data-grid/data-grid.md | 1 - wiki/documentation/data-grid/data-loading.md | 1 - wiki/documentation/data-grid/evictions.md | 1 - wiki/documentation/data-grid/hibernate-l2-cache.md | 1 - wiki/documentation/data-grid/jcache.md | 1 - wiki/documentation/data-grid/off-heap-memory.md | 1 - wiki/documentation/data-grid/persistent-store.md | 1 - wiki/documentation/data-grid/rebalancing.md | 1 - wiki/documentation/data-grid/transactions.md | 1 - .../data-grid/web-session-clustering.md | 1 - .../distributed-data-structures/atomic-types.md | 1 - .../distributed-data-structures/countdownlatch.md | 1 - .../distributed-data-structures/id-generator.md | 1 - .../distributed-data-structures/queue-and-set.md | 1 - .../distributed-events/automatic-batching.md | 1 - wiki/documentation/distributed-events/events.md | 1 - wiki/documentation/distributed-file-system/igfs.md | 1 - .../distributed-messaging/messaging.md | 1 - wiki/documentation/http/configuration.md | 17 ++++------------- wiki/documentation/http/rest-api.md | 1 - wiki/documentation/release-notes/release-notes.md | 1 - .../service-grid/cluster-singletons.md | 1 - .../service-grid/service-configuration.md | 1 - wiki/documentation/service-grid/service-example.md | 1 - wiki/documentation/service-grid/service-grid.md | 1 - 51 files changed, 4 insertions(+), 63 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/basic-concepts/async-support.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/basic-concepts/async-support.md b/wiki/documentation/basic-concepts/async-support.md index 0cce6d3..e434f70 100755 --- a/wiki/documentation/basic-concepts/async-support.md +++ b/wiki/documentation/basic-concepts/async-support.md @@ -15,7 +15,6 @@ limitations under the License. --> - All distributed methods on all Ignite APIs can be executed either synchronously or asynchronously. However, instead of having a duplicate asynchronous method for every synchronous one (like `get()` and `getAsync()`, or `put()` and `putAsync()`, etc.), Ignite chose a more elegant approach, where methods don't have to be duplicated. [block:api-header] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/basic-concepts/getting-started.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/basic-concepts/getting-started.md b/wiki/documentation/basic-concepts/getting-started.md index 71f7b91..705c7a9 100755 --- a/wiki/documentation/basic-concepts/getting-started.md +++ b/wiki/documentation/basic-concepts/getting-started.md @@ -15,7 +15,6 @@ limitations under the License. --> - [block:api-header] { "type": "basic", http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/basic-concepts/ignite-life-cycel.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/basic-concepts/ignite-life-cycel.md b/wiki/documentation/basic-concepts/ignite-life-cycel.md index 88fe54e..d7db8e5 100755 --- a/wiki/documentation/basic-concepts/ignite-life-cycel.md +++ b/wiki/documentation/basic-concepts/ignite-life-cycel.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite is JVM-based. Single JVM represents one or more logical Ignite nodes (most of the time, however, a single JVM runs just one Ignite node). Throughout Ignite documentation we use term Ignite runtime and Ignite node almost interchangeably. For example, when we say that you can "run 5 nodes on this host" - in most cases it technically means that you can start 5 JVMs on this host each running a single Ignite node. Ignite also supports multiple Ignite nodes in a single JVM. In fact, that is exactly how most of the internal tests run for Ignite itself. [block:callout] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/basic-concepts/maven-setup.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/basic-concepts/maven-setup.md b/wiki/documentation/basic-concepts/maven-setup.md index ca60c69..48641d3 100755 --- a/wiki/documentation/basic-concepts/maven-setup.md +++ b/wiki/documentation/basic-concepts/maven-setup.md @@ -15,7 +15,6 @@ limitations under the License. --> - If you are using Maven to manage dependencies of your project, you can import individual Ignite modules a la carte. [block:callout] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/basic-concepts/what-is-ignite.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/basic-concepts/what-is-ignite.md b/wiki/documentation/basic-concepts/what-is-ignite.md index 110f4f0..985ddf4 100755 --- a/wiki/documentation/basic-concepts/what-is-ignite.md +++ b/wiki/documentation/basic-concepts/what-is-ignite.md @@ -15,7 +15,6 @@ limitations under the License. --> - Apache Ignite In-Memory Data Fabric is a high-performance, integrated and distributed in-memory platform for computing and transacting on large-scale data sets in real-time, orders of magnitude faster than possible with traditional disk-based or flash technologies. [block:image] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/basic-concepts/zero-deployment.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/basic-concepts/zero-deployment.md b/wiki/documentation/basic-concepts/zero-deployment.md index da35735..3d43134 100755 --- a/wiki/documentation/basic-concepts/zero-deployment.md +++ b/wiki/documentation/basic-concepts/zero-deployment.md @@ -15,7 +15,6 @@ limitations under the License. --> - The closures and tasks that you use for your computations may be of any custom class, including anonymous classes. In Ignite, the remote nodes will automatically become aware of those classes, and you won't need to explicitly deploy or move any .jar files to any remote nodes. Such behavior is possible due to peer class loading (P2P class loading), a special **distributed ClassLoader** in Ignite for inter-node byte-code exchange. With peer-class-loading enabled, you don't have to manually deploy your Java or Scala code on each node in the grid and re-deploy it each time it changes. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/clustering/aws-config.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/clustering/aws-config.md b/wiki/documentation/clustering/aws-config.md index 5055ff6..154d80d 100755 --- a/wiki/documentation/clustering/aws-config.md +++ b/wiki/documentation/clustering/aws-config.md @@ -15,7 +15,6 @@ limitations under the License. --> - Node discovery on AWS cloud is usually proven to be more challenging. Amazon EC2, just like most of the other virtual environments, has the following limitations: * Multicast is disabled. * TCP addresses change every time a new image is started. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/clustering/cluster-config.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/clustering/cluster-config.md b/wiki/documentation/clustering/cluster-config.md index cd966f3..aef113f 100755 --- a/wiki/documentation/clustering/cluster-config.md +++ b/wiki/documentation/clustering/cluster-config.md @@ -15,7 +15,6 @@ limitations under the License. --> - In Ignite, nodes can discover each other by using `DiscoverySpi`. Ignite provides `TcpDiscoverySpi` as a default implementation of `DiscoverySpi` that uses TCP/IP for node discovery. Discovery SPI can be configured for Multicast and Static IP based node discovery. [block:api-header] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/clustering/cluster-groups.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/clustering/cluster-groups.md b/wiki/documentation/clustering/cluster-groups.md index 85054fd..7899807 100755 --- a/wiki/documentation/clustering/cluster-groups.md +++ b/wiki/documentation/clustering/cluster-groups.md @@ -15,7 +15,6 @@ limitations under the License. --> - `ClusterGroup` represents a logical grouping of cluster nodes. In Ignite all nodes are equal by design, so you don't have to start any nodes in specific order, or assign any specific roles to them. However, Ignite allows users to logically group cluster nodes for any application specific purpose. For example, you may wish to deploy a service only on remote nodes, or assign a role of "worker" to some worker nodes for job execution. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/clustering/cluster.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/clustering/cluster.md b/wiki/documentation/clustering/cluster.md index 68e9218..ce19719 100755 --- a/wiki/documentation/clustering/cluster.md +++ b/wiki/documentation/clustering/cluster.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite nodes can automatically discover each other. This helps to scale the cluster when needed, without having to restart the whole cluster. Developers can also leverage from Igniteâs hybrid cloud support that allows establishing connection between private cloud and public clouds such as Amazon Web Services, providing them with best of both worlds. [block:image] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/clustering/leader-election.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/clustering/leader-election.md b/wiki/documentation/clustering/leader-election.md index fd4e723..1adf45f 100755 --- a/wiki/documentation/clustering/leader-election.md +++ b/wiki/documentation/clustering/leader-election.md @@ -15,7 +15,6 @@ limitations under the License. --> - When working in distributed environments, sometimes you need to have a guarantee that you always will pick the same node, regardless of the cluster topology changes. Such nodes are usually called **leaders**. In many systems electing cluster leaders usually has to do with data consistency and is generally handled via collecting votes from cluster members. Since in Ignite the data consistency is handled by data grid affinity function (e.g. [Rendezvous Hashing](http://en.wikipedia.org/wiki/Rendezvous_hashing)), picking leaders in traditional sense for data consistency outside of the data grid is not really needed. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/clustering/network-config.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/clustering/network-config.md b/wiki/documentation/clustering/network-config.md index d792ea7..c33c919 100755 --- a/wiki/documentation/clustering/network-config.md +++ b/wiki/documentation/clustering/network-config.md @@ -15,7 +15,6 @@ limitations under the License. --> - `CommunicationSpi` provides basic plumbing to send and receive grid messages and is utilized for all distributed grid operations, such as task execution, monitoring data exchange, distributed event querying and others. Ignite provides `TcpCommunicationSpi` as the default implementation of `CommunicationSpi`, that uses the TCP/IP to communicate with other nodes. To enable communication with other nodes, `TcpCommunicationSpi` adds `TcpCommuncationSpi.ATTR_ADDRS` and `TcpCommuncationSpi.ATTR_PORT` local node attributes. At startup, this SPI tries to start listening to local port specified by `TcpCommuncationSpi.setLocalPort(int)` method. If local port is occupied, then SPI will automatically increment the port number until it can successfully bind for listening. `TcpCommuncationSpi.setLocalPortRange(int)` configuration parameter controls maximum number of ports that SPI will try before it fails. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/clustering/node-local-map.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/clustering/node-local-map.md b/wiki/documentation/clustering/node-local-map.md index 8c1967d..23f77de 100755 --- a/wiki/documentation/clustering/node-local-map.md +++ b/wiki/documentation/clustering/node-local-map.md @@ -15,7 +15,6 @@ limitations under the License. --> - Often it is useful to share a state between different compute jobs or different deployed services. For this purpose Ignite provides a shared concurrent **node-local-map** available on each node. [block:code] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/compute-grid/checkpointing.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/compute-grid/checkpointing.md b/wiki/documentation/compute-grid/checkpointing.md index a37b5e9..b7ca7ac 100755 --- a/wiki/documentation/compute-grid/checkpointing.md +++ b/wiki/documentation/compute-grid/checkpointing.md @@ -15,7 +15,6 @@ limitations under the License. --> - Checkpointing provides an ability to save an intermediate job state. It can be useful when long running jobs need to store some intermediate state to protect from node failures. Then on restart of a failed node, a job would load the saved checkpoint and continue from where it left off. The only requirement for job checkpoint state is to implement `java.io.Serializable` interface. Checkpoints are available through the following methods on `GridTaskSession` interface: http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/compute-grid/collocate-compute-and-data.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/compute-grid/collocate-compute-and-data.md b/wiki/documentation/compute-grid/collocate-compute-and-data.md index 81d9642..e4d064e 100755 --- a/wiki/documentation/compute-grid/collocate-compute-and-data.md +++ b/wiki/documentation/compute-grid/collocate-compute-and-data.md @@ -15,7 +15,6 @@ limitations under the License. --> - Collocation of computations with data allow for minimizing data serialization within network and can significantly improve performance and scalability of your application. Whenever possible, you should alway make best effort to colocate your computations with the cluster nodes caching the data that needs to be processed. [block:api-header] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/compute-grid/compute-grid.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/compute-grid/compute-grid.md b/wiki/documentation/compute-grid/compute-grid.md index 4611069..a8863f8 100755 --- a/wiki/documentation/compute-grid/compute-grid.md +++ b/wiki/documentation/compute-grid/compute-grid.md @@ -15,7 +15,6 @@ limitations under the License. --> - Distributed computations are performed in parallel fashion to gain **high performance**, **low latency**, and **linear scalability**. Ignite compute grid provides a set of simple APIs that allow users distribute computations and data processing across multiple computers in the cluster. Distributed parallel processing is based on the ability to take any computation and execute it on any set of cluster nodes and return the results back. [block:image] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/compute-grid/compute-tasks.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/compute-grid/compute-tasks.md b/wiki/documentation/compute-grid/compute-tasks.md index 6573ea4..ef15f15 100755 --- a/wiki/documentation/compute-grid/compute-tasks.md +++ b/wiki/documentation/compute-grid/compute-tasks.md @@ -15,7 +15,6 @@ limitations under the License. --> - `ComputeTask` is the Ignite abstraction for the simplified in-memory MapReduce, which is also very close to ForkJoin paradigm. Pure MapReduce was never built for performance and only works well when dealing with off-line batch oriented processing (e.g. Hadoop MapReduce). However, when computing on data that resides in-memory, real-time low latencies and high throughput usually take the highest priority. Also, simplicity of the API becomes very important as well. With that in mind, Ignite introduced the `ComputeTask` API, which is a light-weight MapReduce (or ForkJoin) implementation. [block:callout] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/compute-grid/distributed-closures.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/compute-grid/distributed-closures.md b/wiki/documentation/compute-grid/distributed-closures.md index 1b53344..035d361 100755 --- a/wiki/documentation/compute-grid/distributed-closures.md +++ b/wiki/documentation/compute-grid/distributed-closures.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite compute grid allows to broadcast and load-balance any closure within the cluster or a cluster group, including plain Java `runnables` and `callables`. [block:api-header] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/compute-grid/executor-service.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/compute-grid/executor-service.md b/wiki/documentation/compute-grid/executor-service.md index a8eeb14..3ea86fc 100755 --- a/wiki/documentation/compute-grid/executor-service.md +++ b/wiki/documentation/compute-grid/executor-service.md @@ -15,7 +15,6 @@ limitations under the License. --> - [IgniteCompute](doc:compute) provides a convenient API for executing computations on the cluster. However, you can also work directly with standard `ExecutorService` interface from JDK. Ignite provides a cluster-enabled implementation of `ExecutorService` and automatically executes all the computations in load-balanced fashion within the cluster. Your computations also become fault-tolerant and are guaranteed to execute as long as there is at least one node left. You can think of it as a distributed cluster-enabled thread pool. [block:code] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/compute-grid/fault-tolerance.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/compute-grid/fault-tolerance.md b/wiki/documentation/compute-grid/fault-tolerance.md index f58e6d5..1eed62d 100755 --- a/wiki/documentation/compute-grid/fault-tolerance.md +++ b/wiki/documentation/compute-grid/fault-tolerance.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite supports automatic job failover. In case of a node crash, jobs are automatically transferred to other available nodes for re-execution. However, in Ignite you can also treat any job result as a failure as well. The worker node can still be alive, but it may be running low on CPU, I/O, disk space, etc. There are many conditions that may result in a failure within your application and you can trigger a failover. Moreover, you have the ability to choose to which node a job should be failed over to, as it could be different for different applications or different computations within the same application. The `FailoverSpi` is responsible for handling the selection of a new node for the execution of a failed job. `FailoverSpi` inspects the failed job and the list of all available grid nodes on which the job execution can be retried. It ensures that the job is not re-mapped to the same node it had failed on. Failover is triggered when the method `ComputeTask.result(...)` returns the `ComputeJobResultPolicy.FAILOVER` policy. Ignite comes with a number of built-in customizable Failover SPI implementations. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/compute-grid/job-scheduling.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/compute-grid/job-scheduling.md b/wiki/documentation/compute-grid/job-scheduling.md index bb83c12..568cbc7 100755 --- a/wiki/documentation/compute-grid/job-scheduling.md +++ b/wiki/documentation/compute-grid/job-scheduling.md @@ -15,7 +15,6 @@ limitations under the License. --> - In Ignite, jobs are mapped to cluster nodes during initial task split or closure execution on the client side. However, once jobs arrive to the designated nodes, then need to be ordered for execution. By default, jobs are submitted to a thread pool and are executed in random order. However, if you need to have a fine-grained control over job ordering, you can enable `CollisionSpi`. [block:api-header] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/compute-grid/load-balancing.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/compute-grid/load-balancing.md b/wiki/documentation/compute-grid/load-balancing.md index 0fb89ed..e249cf2 100755 --- a/wiki/documentation/compute-grid/load-balancing.md +++ b/wiki/documentation/compute-grid/load-balancing.md @@ -15,7 +15,6 @@ limitations under the License. --> - Load balancing component balances job distribution among cluster nodes. In Ignite load balancing is achieved via `LoadBalancingSpi` which controls load on all nodes and makes sure that every node in the cluster is equally loaded. In homogeneous environments with homogeneous tasks load balancing is achieved by random or round-robin policies. However, in many other use cases, especially under uneven load, more complex adaptive load-balancing policies may be needed. [block:callout] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/data-grid/affinity-collocation.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/data-grid/affinity-collocation.md b/wiki/documentation/data-grid/affinity-collocation.md index 5fa7329..6bbfcc5 100755 --- a/wiki/documentation/data-grid/affinity-collocation.md +++ b/wiki/documentation/data-grid/affinity-collocation.md @@ -15,7 +15,6 @@ limitations under the License. --> - Given that the most common ways to cache data is in `PARTITIONED` caches, collocating compute with data or data with data can significantly improve performance and scalability of your application. [block:api-header] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/data-grid/automatic-db-integration.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/data-grid/automatic-db-integration.md b/wiki/documentation/data-grid/automatic-db-integration.md index 979eab6..27ee9bd 100755 --- a/wiki/documentation/data-grid/automatic-db-integration.md +++ b/wiki/documentation/data-grid/automatic-db-integration.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite supports integration with databases 'out-of-the-box' by `org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStore` class that implements `org.apache.ignite.cache.store.CacheStore` interface. Ignite provides utility that will read database metadata and generate POJO classes and XML configuration. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/data-grid/cache-modes.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/data-grid/cache-modes.md b/wiki/documentation/data-grid/cache-modes.md index 5bf2e2b..4bcb3c8 100755 --- a/wiki/documentation/data-grid/cache-modes.md +++ b/wiki/documentation/data-grid/cache-modes.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite provides three different modes of cache operation: `LOCAL`, `REPLICATED`, and `PARTITIONED`. A cache mode is configured for each cache. Cache modes are defined in `CacheMode` enumeration. [block:api-header] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/data-grid/cache-queries.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/data-grid/cache-queries.md b/wiki/documentation/data-grid/cache-queries.md index f197f95..9df0c9e 100755 --- a/wiki/documentation/data-grid/cache-queries.md +++ b/wiki/documentation/data-grid/cache-queries.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite supports a very elegant query API with support for * [Predicate-based Scan Queries](#scan-queries) http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/data-grid/data-grid.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/data-grid/data-grid.md b/wiki/documentation/data-grid/data-grid.md index 2f57126..eed906c 100755 --- a/wiki/documentation/data-grid/data-grid.md +++ b/wiki/documentation/data-grid/data-grid.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite in-memory data grid has been built from the ground up with a notion of horizontal scale and ability to add nodes on demand in real-time; it has been designed to linearly scale to hundreds of nodes with strong semantics for data locality and affinity data routing to reduce redundant data noise. Ignite data grid supports local, replicated, and partitioned data sets and allows to freely cross query between these data sets using standard SQL syntax. Ignite supports standard SQL for querying in-memory data including support for distributed SQL joins. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/data-grid/data-loading.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/data-grid/data-loading.md b/wiki/documentation/data-grid/data-loading.md index 8cd9758..04bf661 100755 --- a/wiki/documentation/data-grid/data-loading.md +++ b/wiki/documentation/data-grid/data-loading.md @@ -15,7 +15,6 @@ limitations under the License. --> - Data loading usually has to do with initializing cache data on startup. Using standard cache `put(...)` or `putAll(...)` operations is generally inefficient for loading large amounts of data. [block:api-header] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/data-grid/evictions.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/data-grid/evictions.md b/wiki/documentation/data-grid/evictions.md index 43232a8..bbf28ae 100755 --- a/wiki/documentation/data-grid/evictions.md +++ b/wiki/documentation/data-grid/evictions.md @@ -15,7 +15,6 @@ limitations under the License. --> - Eviction policies control the maximum number of elements that can be stored in a cache on-heap memory. Whenever maximum on-heap cache size is reached, entries are evicted into [off-heap space](doc:off-heap-memory), if one is enabled. In Ignite eviction policies are pluggable and are controlled via `CacheEvictionPolicy` interface. An implementation of eviction policy is notified of every cache change and defines the algorithm of choosing the entries to evict from cache. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/data-grid/hibernate-l2-cache.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/data-grid/hibernate-l2-cache.md b/wiki/documentation/data-grid/hibernate-l2-cache.md index aebfdd5..5567845 100755 --- a/wiki/documentation/data-grid/hibernate-l2-cache.md +++ b/wiki/documentation/data-grid/hibernate-l2-cache.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite In-Memory Data Fabric can be used as [Hibernate](http://hibernate.org) Second-Level cache (or L2 cache), which can significantly speed-up the persistence layer of your application. [Hibernate](http://hibernate.org) is a well-known and widely used framework for Object-Relational Mapping (ORM). While interacting closely with an SQL database, it performs caching of retrieved data to minimize expensive database requests. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/data-grid/jcache.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/data-grid/jcache.md b/wiki/documentation/data-grid/jcache.md index 29207de..c2ba448 100755 --- a/wiki/documentation/data-grid/jcache.md +++ b/wiki/documentation/data-grid/jcache.md @@ -15,7 +15,6 @@ limitations under the License. --> - Apache Ignite data grid is an implementation of JCache (JSR 107) specification (currently undergoing JSR107 TCK testing). JCache provides a very simple to use, but yet very powerful API for data access. However, the specification purposely omits any details about data distribution and consistency to allow vendors enough freedom in their own implementations. In addition to JCache, Ignite provides ACID transactions, data querying capabilities (including SQL), various memory models, queries, transactions, etc... http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/data-grid/off-heap-memory.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/data-grid/off-heap-memory.md b/wiki/documentation/data-grid/off-heap-memory.md index c12fe06..d184dd8 100755 --- a/wiki/documentation/data-grid/off-heap-memory.md +++ b/wiki/documentation/data-grid/off-heap-memory.md @@ -15,7 +15,6 @@ limitations under the License. --> - Off-Heap memory allows your cache to overcome lengthy JVM Garbage Collection (GC) pauses when working with large heap sizes by caching data outside of main Java Heap space, but still in RAM. [block:image] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/data-grid/persistent-store.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/data-grid/persistent-store.md b/wiki/documentation/data-grid/persistent-store.md index bbd3fbc..ce913a4 100755 --- a/wiki/documentation/data-grid/persistent-store.md +++ b/wiki/documentation/data-grid/persistent-store.md @@ -15,7 +15,6 @@ limitations under the License. --> - JCache specification comes with APIs for [javax.cache.inegration.CacheLoader](https://ignite.incubator.apache.org/jcache/1.0.0/javadoc/javax/cache/integration/CacheLoader.html) and [javax.cache.inegration.CacheWriter](https://ignite.incubator.apache.org/jcache/1.0.0/javadoc/javax/cache/integration/CacheWriter.html) which are used for **write-through** and **read-through** to and from an underlying persistent storage respectively (e.g. an RDBMS database like Oracle or MySQL, or NoSQL database like MongoDB or Couchbase). While Ignite allows you to configure the `CacheLoader` and `CacheWriter` separately, it is very awkward to implement a transactional store within 2 separate classes, as multiple `load` and `put` operations have to share the same connection within the same transaction. To mitigate that, Ignite provides `org.apache.ignite.cache.store.CacheStore` interface which extends both, `CacheLoader` and `CacheWriter`. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/data-grid/rebalancing.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/data-grid/rebalancing.md b/wiki/documentation/data-grid/rebalancing.md index fbe47cc..5ffe6a6 100755 --- a/wiki/documentation/data-grid/rebalancing.md +++ b/wiki/documentation/data-grid/rebalancing.md @@ -15,7 +15,6 @@ limitations under the License. --> - When a new node joins topology, existing nodes relinquish primary or back up ownership of some keys to the new node so that keys remain equally balanced across the grid at all times. If the new node becomes a primary or backup for some partition, it will fetch data from previous primary node for that partition or from one of the backup nodes for that partition. Once a partition is fully loaded to the new node, it will be marked obsolete on the old node and will be eventually evicted after all current transactions on that node are finished. Hence, for some short period of time, after topology changes, there can be a case when a cache will have more backup copies for a key than configured. However once rebalancing completes, extra backup copies will be removed from node caches. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/data-grid/transactions.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/data-grid/transactions.md b/wiki/documentation/data-grid/transactions.md index a87cb53..88a47a0 100755 --- a/wiki/documentation/data-grid/transactions.md +++ b/wiki/documentation/data-grid/transactions.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite supports 2 modes for cache operation, *transactional* and *atomic*. In `transactional` mode you are able to group multiple cache operations in a transaction, while `atomic` mode supports multiple atomic operations, one at a time. `Atomic` mode is more light-weight and generally has better performance over `transactional` caches. However, regardless of which mode you use, as long as your cluster is alive, the data between different cluster nodes must remain consistent. This means that whichever node is being used to retrieve data, it will never get data that has been partially committed or that is inconsistent with other data. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/data-grid/web-session-clustering.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/data-grid/web-session-clustering.md b/wiki/documentation/data-grid/web-session-clustering.md index a6a575c..9968ed1 100755 --- a/wiki/documentation/data-grid/web-session-clustering.md +++ b/wiki/documentation/data-grid/web-session-clustering.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite In-Memory Data Fabric is capable of caching web sessions of all Java Servlet containers that follow Java Servlet 3.0 Specification, including Apache Tomcat, Eclipse Jetty, Oracle WebLogic, and others. Web sessions caching becomes useful when running a cluster of app servers. When running a web application in a servlet container, you may face performance and scalability problems. A single app server is usually not able to handle large volumes of traffic by itself. A common solution is to scale your web application across multiple clustered instances: http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/distributed-data-structures/atomic-types.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/distributed-data-structures/atomic-types.md b/wiki/documentation/distributed-data-structures/atomic-types.md index 1043f19..25446f5 100755 --- a/wiki/documentation/distributed-data-structures/atomic-types.md +++ b/wiki/documentation/distributed-data-structures/atomic-types.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite supports distributed ***atomic long*** and ***atomic reference*** , similar to `java.util.concurrent.atomic.AtomicLong` and `java.util.concurrent.atomic.AtomicReference` respectively. Atomics in Ignite are distributed across the cluster, essentially enabling performing atomic operations (such as increment-and-get or compare-and-set) with the same globally-visible value. For example, you could update the value of an atomic long on one node and read it from another node. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/distributed-data-structures/countdownlatch.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/distributed-data-structures/countdownlatch.md b/wiki/documentation/distributed-data-structures/countdownlatch.md index 68b2eda..f244e97 100755 --- a/wiki/documentation/distributed-data-structures/countdownlatch.md +++ b/wiki/documentation/distributed-data-structures/countdownlatch.md @@ -15,7 +15,6 @@ limitations under the License. --> - If you are familiar with `java.util.concurrent.CountDownLatch` for synchronization between threads within a single JVM, Ignite provides `IgniteCountDownLatch` to allow similar behavior across cluster nodes. A distributed CountDownLatch in Ignite can be created as follows: http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/distributed-data-structures/id-generator.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/distributed-data-structures/id-generator.md b/wiki/documentation/distributed-data-structures/id-generator.md index 3ba7b4f..1793dfb 100755 --- a/wiki/documentation/distributed-data-structures/id-generator.md +++ b/wiki/documentation/distributed-data-structures/id-generator.md @@ -15,7 +15,6 @@ limitations under the License. --> - Distributed atomic sequence provided by `IgniteCacheAtomicSequence` interface is similar to distributed atomic long, but its value can only go up. It also supports reserving a range of values to avoid costly network trips or cache updates every time a sequence must provide a next value. That is, when you perform `incrementAndGet()` (or any other atomic operation) on an atomic sequence, the data structure reserves ahead a range of values, which are guaranteed to be unique across the cluster for this sequence instance. Here is an example of how atomic sequence can be created: http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/distributed-data-structures/queue-and-set.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/distributed-data-structures/queue-and-set.md b/wiki/documentation/distributed-data-structures/queue-and-set.md index b7ca419..4bfe3a8 100755 --- a/wiki/documentation/distributed-data-structures/queue-and-set.md +++ b/wiki/documentation/distributed-data-structures/queue-and-set.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite In-Memory Data Fabric, in addition to providing standard key-value map-like storage, also provides an implementation of a fast Distributed Blocking Queue and Distributed Set. `IgniteQueue` and `IgniteSet`, an implementation of `java.util.concurrent.BlockingQueue` and `java.util.Set` interface respectively, also support all operations from `java.util.Collection` interface. Both, queue and set can be created in either collocated or non-collocated mode. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/distributed-events/automatic-batching.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/distributed-events/automatic-batching.md b/wiki/documentation/distributed-events/automatic-batching.md index ed124a4..f89ffe0 100755 --- a/wiki/documentation/distributed-events/automatic-batching.md +++ b/wiki/documentation/distributed-events/automatic-batching.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite automatically groups or batches event notifications that are generated as a result of cache events occurring within the cluster. Each activity in cache can result in an event notification being generated and sent. For systems where cache activity is high, getting notified for every event could be network intensive, possibly leading to a decreased performance of cache operations in the grid. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/distributed-events/events.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/distributed-events/events.md b/wiki/documentation/distributed-events/events.md index eb43fee..2c7f43a 100755 --- a/wiki/documentation/distributed-events/events.md +++ b/wiki/documentation/distributed-events/events.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite distributed events functionality allows applications to receive notifications when a variety of events occur in the distributed grid environment. You can automatically get notified for task executions, read, write or query operations occurring on local or remote nodes within the cluster. Distributed events functionality is provided via `IgniteEvents` interface. You can get an instance of `IgniteEvents` from Ignite as follows: http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/distributed-file-system/igfs.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/distributed-file-system/igfs.md b/wiki/documentation/distributed-file-system/igfs.md index fcefcef..ca11fd8 100755 --- a/wiki/documentation/distributed-file-system/igfs.md +++ b/wiki/documentation/distributed-file-system/igfs.md @@ -15,5 +15,4 @@ limitations under the License. --> - We are currently adding documentation for the Ignite File System. In the mean time you can refer to the [javadoc](https://ignite.incubator.apache.org/releases/1.0.0/javadoc/org/apache/ignite/IgniteFs.html). \ No newline at end of file http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/distributed-messaging/messaging.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/distributed-messaging/messaging.md b/wiki/documentation/distributed-messaging/messaging.md index f526b45..92871b9 100755 --- a/wiki/documentation/distributed-messaging/messaging.md +++ b/wiki/documentation/distributed-messaging/messaging.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite distributed messaging allows for topic based cluster-wide communication between all nodes. Messages with a specified message topic can be distributed to all or sub-group of nodes that have subscribed to that topic. Ignite messaging is based on publish-subscribe paradigm where publishers and subscribers are connected together by a common topic. When one of the nodes sends a message A for topic T, it is published on all nodes that have subscribed to T. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/http/configuration.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/http/configuration.md b/wiki/documentation/http/configuration.md index ec5a4ad..4696661 100755 --- a/wiki/documentation/http/configuration.md +++ b/wiki/documentation/http/configuration.md @@ -15,7 +15,6 @@ limitations under the License. --> - [block:api-header] { "type": "basic", @@ -30,29 +29,21 @@ "h-3": "Default value", "h-2": "Optional", "h-1": "Description", - "0-0": "**setRestSecretKey(String)**", + "0-0": "**setSecretKey(String)**", "0-1": "Defines secret key used for client authentication. When provided, client request must contain HTTP header **X-Signature** with Base64 encoded SHA1 hash of the string \"[1];[2]\", where [1] is timestamp in milliseconds and [2] is the secret key.", "0-3": "**null**", "0-2": "Yes", - "1-0": "**setRestPortRange(int)**", + "1-0": "**setPortRange(int)**", "1-1": "Port range for Jetty server. In case port provided in Jetty configuration or **IGNITE_JETTY_PORT** system property is already in use, Ignite will iteratively increment port by 1 and try binding once again until provided port range is exceeded.", "1-3": "**100**", "1-2": "Yes", - "3-0": "**setRestEnabled(Boolean)**", - "3-1": "Whether REST client is enabled or not.", - "3-3": "**true**", - "3-2": "Yes", - "4-0": "**setRestAccessibleFolders(String...)**", - "4-1": "Array of folders that are accessible for log reading commands. When remote client requests a log file, file path is checked against this list. If requested file is not located in any sub-folder of these folders, request is not processed. By default array consists of a single **IGNITE_HOME** folder. If **IGNITE_HOME** could not be detected and property is not specified, no restrictions applied.", - "4-2": "Yes", - "4-3": "**IGNITE_HOME**", - "2-0": "**setRestJettyPath(String)**", + "2-0": "**setJettyPath(String)**", "2-1": "Path to Jetty configuration file. Should be either absolute or relative to **IGNITE_HOME**. If not provided then GridGain will start Jetty server with simple HTTP connector. This connector will use **IGNITE_JETTY_HOST** and **IGNITE_JETTY_PORT** system properties as host and port respectively. In case **IGNITE_JETTY_HOST** is not provided, localhost will be used as default. In case **IGNITE_JETTY_PORT** is not provided, port 8080 will be used as default.", "2-3": "**null**", "2-2": "Yes" }, "cols": 4, - "rows": 5 + "rows": 3 } [/block] http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/http/rest-api.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/http/rest-api.md b/wiki/documentation/http/rest-api.md index 99ab278..26f3240 100755 --- a/wiki/documentation/http/rest-api.md +++ b/wiki/documentation/http/rest-api.md @@ -15,7 +15,6 @@ limitations under the License. --> - Ignite provides HTTP REST client that gives you the ability to communicate with the grid over HTTP and HTTPS protocols using REST approach. REST APIs can be used to perform various operations like read/write from/to cache, execute tasks, get cache and node metrics and more. * [Returned value](#returned-value) http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/release-notes/release-notes.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/release-notes/release-notes.md b/wiki/documentation/release-notes/release-notes.md index 2417116..af4b352 100755 --- a/wiki/documentation/release-notes/release-notes.md +++ b/wiki/documentation/release-notes/release-notes.md @@ -15,7 +15,6 @@ limitations under the License. --> - ##Apache Ignite In-Memory Data Fabric 1.0 This is the first release of Apache Ignite project. The source code is based on the 7 year old GridGain In-Memory Data Fabric, open source edition, v. 6.6.2, which was donated to Apache Software Foundation in September 2014. http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/service-grid/cluster-singletons.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/service-grid/cluster-singletons.md b/wiki/documentation/service-grid/cluster-singletons.md index fa4e5a3..0b7beec 100755 --- a/wiki/documentation/service-grid/cluster-singletons.md +++ b/wiki/documentation/service-grid/cluster-singletons.md @@ -15,7 +15,6 @@ limitations under the License. --> - `IgniteServices` facade allows to deploy any number of services on any of the grid nodes. However, the most commonly used feature is to deploy singleton services on the cluster. Ignite will manage the singleton contract regardless of topology changes and node crashes. [block:callout] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/service-grid/service-configuration.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/service-grid/service-configuration.md b/wiki/documentation/service-grid/service-configuration.md index be0d65c..61343da 100755 --- a/wiki/documentation/service-grid/service-configuration.md +++ b/wiki/documentation/service-grid/service-configuration.md @@ -15,7 +15,6 @@ limitations under the License. --> - In addition to deploying managed services by calling any of the provided `IgniteServices.deploy(...)` methods, you can also automatically deploy services on startup by setting `serviceConfiguration` property of IgniteConfiguration: [block:code] { http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/service-grid/service-example.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/service-grid/service-example.md b/wiki/documentation/service-grid/service-example.md index 333fc9e..e316af5 100755 --- a/wiki/documentation/service-grid/service-example.md +++ b/wiki/documentation/service-grid/service-example.md @@ -15,7 +15,6 @@ limitations under the License. --> - [block:api-header] { "type": "basic", http://git-wip-us.apache.org/repos/asf/incubator-ignite/blob/3e65882a/wiki/documentation/service-grid/service-grid.md ---------------------------------------------------------------------- diff --git a/wiki/documentation/service-grid/service-grid.md b/wiki/documentation/service-grid/service-grid.md index 742147e..1620e93 100755 --- a/wiki/documentation/service-grid/service-grid.md +++ b/wiki/documentation/service-grid/service-grid.md @@ -15,7 +15,6 @@ limitations under the License. --> - Service Grid allows for deployments of arbitrary user-defined services on the cluster. You can implement and deploy any service, such as custom counters, ID generators, hierarchical maps, etc. Ignite allows you to control how many instances of your service should be deployed on each cluster node and will automatically ensure proper deployment and fault tolerance of all the services .
