more markdown cleanup

Author: jowens

README.md

@@ -421,7 +421,7 @@ A `Codec` object encodes and decodes _wire_ protocols, such as HTTP. You can use
 
 In Finagle, RPC servers are built out of a `Service` and zero or more `Filter` objects. You apply filters to the service request after which you execute the service itself:
 
-![Relationship between a service and filters (doc/Filters.png)](https://github.com/jdowens/finagle/raw/master/doc/Filters.png)
+![Relationship between a service and filters (doc/Filters.png)](https://github.com/twitter/finagle/raw/master/doc/Filters.png)
 
 Typically, you use a `ServerBuilder` to create your server. A `ServerBuilder` enables you to specify the following general attributes:
 
@@ -1164,7 +1164,7 @@ A client can access a cluster, as follows:
 
 
 
-<a href="Configuring Finagle Servers and Clients"</a>
+<a href="Configuring Finagle Servers and Clients"></a>
 
 ## Configuring Finagle Servers and Clients
 
@@ -1198,7 +1198,7 @@ Next we note the required parameters for the `ClientBuilder`.
 
 When diving into configuration, we see two main abstractions. The first is the trio of client, hosts, and connections. A client may be implemented as a collection of one or more hosts, together with a policy that distributes client machines among the hosts. And each host may allow one or more connections to it, exposing concurrency among requests to the client and allowing parallel execution. 
 
-![Relationship between clients, hosts, and connections. (doc/client-hosts-connections.svg)](https://github.com/twitter/finagle/raw/master/doc/client-hosts-connections.svg)
+![Relationship between clients, hosts, and connections. (doc/client-hosts-connections.svg)](https://github.com/jdowens/finagle/raw/master/doc/client-hosts-connections.svg)
 
 The second main abstraction is the codec, which is responsible for turning a stream of bytes into a discrete request or response.
 
@@ -1218,12 +1218,12 @@ The purpose of a Cluster is to abstract a group of identical servers, where requ
 
 > The Finagle balancing strategy is to pick the endpoint with the least number of outstanding requests, which is similar to a *least connections* strategy in other load balancers. The Finagle load balancer deliberately introduces jitter to avoid synchronicity (and thundering herds) in a distributed system. It also supports failover.
 
-The simplest way to implement a custom load balancing strategy is to create your own client per endpoint and then write your own load balancer across that. The <a href="https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/loadbalancer/HeapBalancer.scala">HeapBalancer</a> code provides a solid starting point; note it uses a heap to identify the endpoint with the least number of requests (`Ordering.by { _.load `}, where {load} is the number of connections).
+The simplest way to implement a custom load balancing strategy is to create your own client per endpoint and then write your own load balancer across that. The <a href="https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/loadbalancer/HeapBalancer.scala">HeapBalancer</a> code provides a solid starting point; note it uses a heap to identify the endpoint with the least number of requests (`Ordering.by { _.load }`, where `load` is the number of connections).
 
 
 ### Idle Times
 
-.bq `hostConnectionIdleTime` vs. `hostConnectionMaxIdleTime`: with respect to the `ClientBuilder`, what's the difference?
+> `hostConnectionIdleTime` vs. `hostConnectionMaxIdleTime`: with respect to the `ClientBuilder`, what's the difference?
 
 `hostConnectionIdleTime` applies to the pool: "the amount of time a connection is allowed to linger (when it otherwise would have been closed by the pool) before being closed". `hostConnectionMaxIdleTime` applies to the physical connection: "the maximum time a connection is allowed to linger unused".