Fix links pointing to wrong docs url

Project: http://git-wip-us.apache.org/repos/asf/incubator-geode/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-geode/commit/4cd59adb
Tree: http://git-wip-us.apache.org/repos/asf/incubator-geode/tree/4cd59adb
Diff: http://git-wip-us.apache.org/repos/asf/incubator-geode/diff/4cd59adb

Branch: refs/heads/gh-wiki
Commit: 4cd59adb9982fd1fccee66de9851c5e97541c8d9
Parents: 269c03a
Author: Anthony Baker <[email protected]>
Authored: Fri Apr 10 13:20:03 2015 -0700
Committer: Anthony Baker <[email protected]>
Committed: Fri Apr 10 13:20:43 2015 -0700

----------------------------------------------------------------------
 Native-Disk-Persistence.md          | 12 ++++++------
 Organizations-using-Apache-Fuego.md |  1 -
 Releases.md                         |  5 -----
 Resource-Management-in-Geode.md     | 20 ++++++++++----------
 Sizing-a-Geode-Cluster.md           |  2 +-
 Technology-FAQ.md                   |  4 ++--
 6 files changed, 19 insertions(+), 25 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/4cd59adb/Native-Disk-Persistence.md
----------------------------------------------------------------------
diff --git a/Native-Disk-Persistence.md b/Native-Disk-Persistence.md
index c97555d..8311a3f 100644
--- a/Native-Disk-Persistence.md
+++ b/Native-Disk-Persistence.md
@@ -67,7 +67,7 @@ The above indicates a partitioned region with default 
attribute: data-policy:  P
 
 The above chooses to bypass the region shortcut:  
REPLICATE_PERSISTENT_OVERFLOW and simply specifies all attributes for a 
persisted replicated region with overflow.  In most cases you will also want to 
set the scope region attribute to distributed-ack although any of the scopes 
can be used with a persistent region.   For more information on configuring 
persistence and overflow, see 
 
-http://geode-docs.cfapps.io/docs-gemfire/developing/storing_data_on_disk/storing_data_on_disk.html
+http://geode-docs.cfapps.io/docs/developing/storing_data_on_disk/storing_data_on_disk.html
 
 ##How persistence works
 
@@ -87,7 +87,7 @@ Because oplogs are only appended, your disk usage will 
continue to grow until th
 
 The advantage of this two staged approach is that the synchronous writes to 
disk that your application must wait for are only to the oplog. Because the 
oplogs are only appended to writes can be made to the oplog without causing the 
disk head to seek. 
 
-Further reading on how persistence works, see 
http://geode-docs.cfapps.io/docs-gemfire/developing/storing_data_on_disk/how_persist_overflow_work.html
+Further reading on how persistence works, see 
http://geode-docs.cfapps.io/docs/developing/storing_data_on_disk/how_persist_overflow_work.html
 
 ###What disks and directories will be used?
 
@@ -97,7 +97,7 @@ To declare the _disk-dirs_ in cache.xml add a _disk-dir_ 
sub-element to the _dis
 
 Note that an optional _dir-size_ can also be configured. For further 
information, see 
 
-http://geode-docs.cfapps.io/docs-gemfire/managing/disk_storage/disk_store_configuration_params.html
+http://geode-docs.cfapps.io/docs/managing/disk_storage/disk_store_configuration_params.html
  
 ###Useful Information
 
@@ -150,10 +150,10 @@ When an oplog is full, Geode closes it and a new log with 
the next sequence numb
 
 ####Further reading 
 Disk Storage operation logs:
- 
http://geode-docs.cfapps.io/docs-gemfire/managing/disk_storage/operation_logs.html
 
+ http://geode-docs.cfapps.io/docs/managing/disk_storage/operation_logs.html 
 
 System startup with disk stores:
-http://geode-docs.cfapps.io/docs-gemfire/managing/disk_storage/how_startup_works_in_system_with_disk_stores.html#how_startup_works_in_system_with_disk_stores
+http://geode-docs.cfapps.io/docs/managing/disk_storage/how_startup_works_in_system_with_disk_stores.html#how_startup_works_in_system_with_disk_stores
 
 ###When is data written to disk?
 
@@ -427,4 +427,4 @@ removes     The total entry destroys handed off to the disk 
layer. </td>
 
 ####CachePerfStatistics
 
-The CachePerfStatistics instance has a statistic named rollsWaiting which 
tells you how many of this VM's disk regions are ready to roll an oplog to the 
db files but are waiting for a thread to be available to do this work.
\ No newline at end of file
+The CachePerfStatistics instance has a statistic named rollsWaiting which 
tells you how many of this VM's disk regions are ready to roll an oplog to the 
db files but are waiting for a thread to be available to do this work.

http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/4cd59adb/Organizations-using-Apache-Fuego.md
----------------------------------------------------------------------
diff --git a/Organizations-using-Apache-Fuego.md 
b/Organizations-using-Apache-Fuego.md
deleted file mode 100644
index b306557..0000000
--- a/Organizations-using-Apache-Fuego.md
+++ /dev/null
@@ -1 +0,0 @@
-List of customer references for GemFire - use existing.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/4cd59adb/Releases.md
----------------------------------------------------------------------
diff --git a/Releases.md b/Releases.md
deleted file mode 100644
index 8e06b03..0000000
--- a/Releases.md
+++ /dev/null
@@ -1,5 +0,0 @@
-#Geode Release Information
-
-##Geode 1.0.0.0
-
-###Known Issues
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/4cd59adb/Resource-Management-in-Geode.md
----------------------------------------------------------------------
diff --git a/Resource-Management-in-Geode.md b/Resource-Management-in-Geode.md
index f349754..1a76ecb 100644
--- a/Resource-Management-in-Geode.md
+++ b/Resource-Management-in-Geode.md
@@ -14,35 +14,35 @@ Geode manages data in memory (with the ability to overflow 
or persist to disk ba
 
 **_Eviction:_**
 
-Geode allows each cache server to specify data policies to control the amount 
of data stored in the server. If eviction is used, then it automatically 
implies that Geode is being used as a cache and if an entry cannot be found in 
the cache, there is an alternate data store from which it can be loaded. [Read 
more about eviction here] 
(http://geode-docs.cfapps.io/docs-gemfire/developing/eviction/chapter_overview.html).
+Geode allows each cache server to specify data policies to control the amount 
of data stored in the server. If eviction is used, then it automatically 
implies that Geode is being used as a cache and if an entry cannot be found in 
the cache, there is an alternate data store from which it can be loaded. [Read 
more about eviction here] 
(http://geode-docs.cfapps.io/docs/developing/eviction/chapter_overview.html).
 
 **_Rebalancing:_**
 
-Depending on the number of servers and the partitioning policies used to 
partition the data, it is possible for some servers to end up hosting more data 
than other server. A server may end up hosting more data to provide redundancy 
for another server that might have been taken down for maintenance perhaps. 
Rebalancing allows data to be migrated from one server to another, ensuring 
that each server is only handling as much data as it is capable of dealing 
with. This allows each VM to control its memory footprint (as well as data 
workload). For more on rebalancing, read [Rebalancing Partitioned Region Data] 
(http://geode-docs.cfapps.io/docs-gemfire/developing/partitioned_regions/rebalancing_pr_data.html).
+Depending on the number of servers and the partitioning policies used to 
partition the data, it is possible for some servers to end up hosting more data 
than other server. A server may end up hosting more data to provide redundancy 
for another server that might have been taken down for maintenance perhaps. 
Rebalancing allows data to be migrated from one server to another, ensuring 
that each server is only handling as much data as it is capable of dealing 
with. This allows each VM to control its memory footprint (as well as data 
workload). For more on rebalancing, read [Rebalancing Partitioned Region Data] 
(http://geode-docs.cfapps.io/docs/developing/partitioned_regions/rebalancing_pr_data.html).
 
 **_The Geode resource manager:_**
 
 The Geode resource manager works closely with the server VM's tenured garbage 
collector to control heap usage and ensures that the server remains responsive 
under heavy load conditions and more importantly ensures that the server 
cluster does not suffer any QoS degradation due to the load on one of the 
servers. 
-For more about the Geode resource manager, read [How the Resource Manager 
Works] 
(http://geode-docs.cfapps.io/docs-gemfire/managing/heap_use/how_the_resource_manager_works.html).
+For more about the Geode resource manager, read [How the Resource Manager 
Works] 
(http://geode-docs.cfapps.io/docs/managing/heap_use/how_the_resource_manager_works.html).
 
 **_Disk Overflow:_**
 
 Geode regions store entries which are comprised of keys and values. Values can 
be large nested complex objects which take up a lot of space on the server 
heap. Geode regions can be configured to overflow values to disk to control the 
memory footprint within the server. 
-For more about overflowing entries to disk and configuring regions with the 
disk attributes for overflow, read [Disk Storage] 
(http://geode-docs.cfapps.io/docs-gemfire/managing/disk_storage/chapter_overview.html).
+For more about overflowing entries to disk and configuring regions with the 
disk attributes for overflow, read [Disk Storage] 
(http://geode-docs.cfapps.io/docs/managing/disk_storage/chapter_overview.html).
 
 **_Managing memory footprint of client subscriptions:_**
 
-In the client-server topology, Geode client applications establish 
subscriptions with the server and qualifying updates are queued up for delivery 
to clients. These queues contain references to the entries that get dispatched 
to the client. Client queues can be configured to overflow to disk to reduce 
the memory footprint of the cache server. The implementation ensures that there 
is no unnecessary memory usage while fetching the entries from disk and 
delivering them to clients. [Read more about client subscriptions here] 
(http://geode-docs.cfapps.io/docs-gemfire/topologies_and_comm/cs_configuration/chapter_overview.html).
+In the client-server topology, Geode client applications establish 
subscriptions with the server and qualifying updates are queued up for delivery 
to clients. These queues contain references to the entries that get dispatched 
to the client. Client queues can be configured to overflow to disk to reduce 
the memory footprint of the cache server. The implementation ensures that there 
is no unnecessary memory usage while fetching the entries from disk and 
delivering them to clients. [Read more about client subscriptions here] 
(http://geode-docs.cfapps.io/docs/topologies_and_comm/cs_configuration/chapter_overview.html).
 ### Network:
 Geode cache servers can be configured to use TCP, reliable unicast or reliable 
multi-cast as the communication protocol for exchanging metadata, as well as 
distributing data across the server cluster. Client applications use TCP to 
communicate with servers. Clients generally connect to multiple servers 
depending on their data access needs and also to ensure redundancy for their 
subscription queues. 
-Server clusters that use TCP to communicate with each other also pool their 
connections and use idle time algorithms to return connections to the pool or 
close connections when they are not needed. For more on connection management 
within the cluster, read [Topologies and Communication] 
(http://geode-docs.cfapps.io/docs-gemfire/topologies_and_comm/book_intro.html).
+Server clusters that use TCP to communicate with each other also pool their 
connections and use idle time algorithms to return connections to the pool or 
close connections when they are not needed. For more on connection management 
within the cluster, read [Topologies and Communication] 
(http://geode-docs.cfapps.io/docs/topologies_and_comm/book_intro.html).
 
 The goal with connection management and connection timeouts is to scale and 
actively manage the amount of workload that needs to be handled by each cache 
server. 
-Each server can be configured [with a maximum client limit] 
(http://geode-docs.cfapps.io/docs-gemfire/topologies_and_comm/cs_configuration/chapter_overview.html).
+Each server can be configured [with a maximum client limit] 
(http://geode-docs.cfapps.io/docs/topologies_and_comm/cs_configuration/chapter_overview.html).
 In addition to this, Geode allows customers to configure a custom load probe, 
which essentially reports the overall load factor on a server VM. A custom load 
probe implements a pre-defined interface and the information it provides is 
used to redirect existing and new client connections to servers that are 
lightly loaded to ensure better QoS. 
 Clients pool their connections to servers as well, leasing them out to 
application threads for accessing data on the server and returning the 
connections to the pool when the application thread has completed its data 
access. 
 Pooled client connections can be configured to expire, which gives the server 
cluster the opportunity to rebalance connections and ensure that each server is 
able to service its clients optimally. 
-Last but not the least, the ability to efficiently serialize objects over the 
network using a [language neutral wire protocol] 
(http://geode-docs.cfapps.io/docs-gemfire/developing/data_serialization/chapter_overview.html)
 and transmit object deltas to receivers limits the amount of bandwidth use and 
allows applications to make effective use of this resource in conjunction with 
the other resources that impact application QoS. The DataSerializable protocol 
in Geode provides an extremely byte-efficient representation of the object on 
the wire reducing bandwidth consumption when the object is transmitted across 
machine boundaries. Efficient wire representation also reduces CPU usage when 
the bytes are sent on the wire. In most real world deployments, when an object 
is frequently updated, there is a small part of the object that gets updated 
(like price on an object representing a stock symbol). The ability to identify 
what part of the object was changed, and then serialize just those ch
 anges and apply them elsewhere, without compromising on data consistency (aka 
[Delta Propagation] 
(http://geode-docs.cfapps.io/docs-gemfire/developing/delta_propagation/chapter_overview.html))
 further optimizes the wire protocol, reduces garbage generation, improves 
bandwidth utilization and reduces CPU usage.
+Last but not the least, the ability to efficiently serialize objects over the 
network using a [language neutral wire protocol] 
(http://geode-docs.cfapps.io/docs/developing/data_serialization/chapter_overview.html)
 and transmit object deltas to receivers limits the amount of bandwidth use and 
allows applications to make effective use of this resource in conjunction with 
the other resources that impact application QoS. The DataSerializable protocol 
in Geode provides an extremely byte-efficient representation of the object on 
the wire reducing bandwidth consumption when the object is transmitted across 
machine boundaries. Efficient wire representation also reduces CPU usage when 
the bytes are sent on the wire. In most real world deployments, when an object 
is frequently updated, there is a small part of the object that gets updated 
(like price on an object representing a stock symbol). The ability to identify 
what part of the object was changed, and then serialize just those changes an
 d apply them elsewhere, without compromising on data consistency (aka [Delta 
Propagation] 
(http://geode-docs.cfapps.io/docs/developing/delta_propagation/chapter_overview.html))
 further optimizes the wire protocol, reduces garbage generation, improves 
bandwidth utilization and reduces CPU usage.
 
 ### CPU:
 The Geode cluster provides distributed data management to applications at very 
high levels of throughput and extremely low latencies. It receives updates to 
data from many different sources and needs to propagate them to the relevant 
cluster members to ensure data consistency to applications. All of this makes 
each server a very parallelized entity that makes heavy use of multi-threading 
to do its work. Geode makes efficient use of thread pools and queues to deliver 
some of the key benefits of Staged Event Driven Architectures (viz. High 
Concurrency, Load conditioning, scalable I/O and so on). In a later section, we 
will see how resource management for each managed resource in a cache works to 
ensure optimal performance of each cache server in the cluster.
@@ -52,13 +52,13 @@ Writing to disk offers reliability at the cost of 
performance. Disk space is tre
 Geode regions that are configured to overflow or persist can configure disk 
artifacts to go to multiple disk directories that may reside on different 
spindles. 
 For each disk directory, a maximum size can be specified. Writes to disk can 
be synchronous or asynchronous depending on the trade-offs the application 
wishes to make between performance and reliability. 
 In addition to this, disk files (also known as Oplogs) can be periodically 
rolled to reduce the number of files used by Geode concurrently. 
-For more on disk attributes, disk tuning and persistence, read [Disk Storage] 
(http://geode-docs.cfapps.io/docs-gemfire/managing/disk_storage/chapter_overview.html).
+For more on disk attributes, disk tuning and persistence, read [Disk Storage] 
(http://geode-docs.cfapps.io/docs/managing/disk_storage/chapter_overview.html).
 ## Workload management in Geode
 In previous sections, we touched upon the various resources that need to be 
managed by Geode and provided details on how Geode accomplishes the same. As 
you may have recognized by now, imbalance in one resource can exacerbate issues 
with other resources and can cause performance degradation and an inability to 
provide QoS to end user applications accessing the cluster. 
 A server that uses up too much memory will get hit by garbage collection 
pauses which will cause clients connected up to it to fail over to other 
servers, causing unnecessary network traffic and increase resource usage on the 
other servers, increasing CPU and potentially disk usage on them. 
 In order to prevent problems of this nature, it is important to do proper 
capacity planning for your Geode installation. You can find more on [capacity 
planning here] 
 
(http://www.gemstone.com/docs/html/gemfire/6.0.0/DevelopersGuide/DataConservation.12.19.html).
 This developer note also provides some practical guidelines for [capacity 
planning in 
Geode](http://community.gemstone.com/display/gemfire/Best+Practices+and+Capacity+Planning+guide).
-Function execution and [querying] 
(http://geode-docs.cfapps.io/docs-gemfire/developing/querying_basics/chapter_overview.html)
 are two Geode capabilities that impact performance and need to be considered 
as part of capacity planning. Function execution and querying can use up CPU, 
cause message traffic on the network and generate transient data causing the 
garbage collector to get engaged.
+Function execution and [querying] 
(http://geode-docs.cfapps.io/docs/developing/querying_basics/chapter_overview.html)
 are two Geode capabilities that impact performance and need to be considered 
as part of capacity planning. Function execution and querying can use up CPU, 
cause message traffic on the network and generate transient data causing the 
garbage collector to get engaged.
 Unlike capacity planning for data volumes and number of clients that access 
the cluster, function execution and querying are harder to plan and predict 
because the functions execute in the server process and queries run on the 
server and both of these can do arbitrarily complex things, the process for 
adding queries and functions should be done just like queries are approved for 
a traditional relational database. When a new query needs to be added to a 
relational database, the query has to be approved by the database adminstrator, 
who considers the impact of the query on the overall system, adds new indexes 
as appropriate, creates views if needed  and only then is the query added to 
the system. With function execution, if the function does a lot of updates, 
then it need to be called out as such so that it can be routed efficiently. 
Also, if a function needs to access related regions, then it might make sense 
to co-locate those regions to improve execution times on the function and 
 also to reduce network round trips to fetch any required information.
 
 ## Resource management and GC tuning

http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/4cd59adb/Sizing-a-Geode-Cluster.md
----------------------------------------------------------------------
diff --git a/Sizing-a-Geode-Cluster.md b/Sizing-a-Geode-Cluster.md
index 00e6af3..3b82737 100644
--- a/Sizing-a-Geode-Cluster.md
+++ b/Sizing-a-Geode-Cluster.md
@@ -40,7 +40,7 @@ Listed below are factors that can have significant impact on 
the memory overhead
 * Choice of Keys. Smaller and simpler keys are more efficient in terms of both 
space and performance.
 * Use of indexes. Indexing incurs a per entry overhead, as documented in the 
below mentioned section of the User’s Guide. 
 
-The section [Memory Requirements for Cached 
Data](http://geode-docs.cfapps.io/docs-gemfire/reference/topics/memory_requirements_for_cache_data.html)
 of the GemFire User’s Guide provides more detailed information and 
guidelines on this topic.
+The section [Memory Requirements for Cached 
Data](http://geode-docs.cfapps.io/docs/reference/topics/memory_requirements_for_cache_data.html)
 of the GemFire User’s Guide provides more detailed information and 
guidelines on this topic.
 
 If the data value objects are small, but great in number, the per-entry 
overhead can add up to a significant memory requirement. This overhead can be 
reduced by grouping multiple data values into a single entry or by using 
containment relationships. For instance, you may choose to have your Order 
objects contain their line items instead of having a separate OrderLineItems 
region. If this option is available, it is worth considering as it may yield 
performance improvements in addition to space savings. 
 

http://git-wip-us.apache.org/repos/asf/incubator-geode/blob/4cd59adb/Technology-FAQ.md
----------------------------------------------------------------------
diff --git a/Technology-FAQ.md b/Technology-FAQ.md
index b45856d..8ef7f7c 100644
--- a/Technology-FAQ.md
+++ b/Technology-FAQ.md
@@ -18,7 +18,7 @@ Geode has been deployed to run mission-critical applications 
on clusters with 10
 
 ### What operating systems are supported?
 
-Geode is supported on most JDK platforms including Linux and Windows. For more 
details please check the [certification 
matrix](http://geode-docs.cfapps.io/docs-gemfire/getting_started/system_requirements/supported_configurations.html#system_requirements).
 
+Geode is supported on most JDK platforms including Linux and Windows. For more 
details please check the [certification 
matrix](http://geode-docs.cfapps.io/docs/getting_started/system_requirements/supported_configurations.html#system_requirements).
 
 
 ### How does my application connect to a Geode cluster?
 
@@ -56,7 +56,7 @@ Bulk synchronization is performed in the event of the failure 
of a member or whe
 
 Keys are hash-partitioned over a fixed number of buckets (the default bucket 
count is 113).  Buckets are automatically balanced across the cluster members 
based on data size, redundancy, and availability zones.
  
-### How Geode handle a network partition?
+### How does Geode handle a network partition?
 
 The network partition detection system is based on quorum and liveness checks. 
 If a member shuts down due to a network partition it will periodically attempt 
to reconnect and rebuild its cache, recovering data either from disk or from 
redundant storage in other members.
 

Reply via email to