activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chir...@apache.org
Subject svn commit: r961238 - in /activemq/sandbox/activemq-apollo-actor: ./ apollo-website/src/ apollo-website/src/styles/impact/css/
Date Wed, 07 Jul 2010 04:41:35 GMT
Author: chirino
Date: Wed Jul  7 04:41:34 2010
New Revision: 961238

URL: http://svn.apache.org/viewvc?rev=961238&view=rev
Log:
styling

Modified:
    activemq/sandbox/activemq-apollo-actor/apollo-website/src/architecture.page
    activemq/sandbox/activemq-apollo-actor/apollo-website/src/index.page
    activemq/sandbox/activemq-apollo-actor/apollo-website/src/metainfo
    activemq/sandbox/activemq-apollo-actor/apollo-website/src/mirgration-guide.page
    activemq/sandbox/activemq-apollo-actor/apollo-website/src/module-organization.page
    activemq/sandbox/activemq-apollo-actor/apollo-website/src/network-design.page
    activemq/sandbox/activemq-apollo-actor/apollo-website/src/privacy-policy.page
    activemq/sandbox/activemq-apollo-actor/apollo-website/src/styles/impact/css/site.css
    activemq/sandbox/activemq-apollo-actor/apollo-website/src/todo.page
    activemq/sandbox/activemq-apollo-actor/readme.md

Modified: activemq/sandbox/activemq-apollo-actor/apollo-website/src/architecture.page
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/apollo-website/src/architecture.page?rev=961238&r1=961237&r2=961238&view=diff
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/apollo-website/src/architecture.page (original)
+++ activemq/sandbox/activemq-apollo-actor/apollo-website/src/architecture.page Wed Jul  7
04:41:34 2010
@@ -14,110 +14,85 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
-title: Architectural Overview
-in_menu: true
---- name:overview pipeline:haml,tags
+title: Architecture
+--- name:content
 
-%h1 {project_name:} Architecture
+## Architectural Changes
 
-Explore the core components that make this next generation Broker work.
+Apollo started as an experiment to see what it would take to make ActiveMQ
+work better on machines with higher core counts. It has resulted in broker
+that is much more deterministic, stable, and scaleable.
+
+The major fundamental architectural changes it brings are:
+
+* Reactor Based Thread Model
+* Scala 2.8 Implementation
+* Protocol Agnostic
+* REST Based Management
+
+### Reactor Based Thread Model
+
+Apollo uses [HawtDispatch][] to implement the sever using a multi-threaded
+non-blocking variation of the [reactor][] design pattern. HawtDispatch is a
+Java clone of [libdispatch][] (aka [Grand Central Dispatch][gcd]). It uses a
+fixed sized thread pool and only executes non-blocking tasks on those
+threads.
+
+[reactor]:http://en.wikipedia.org/wiki/Reactor_pattern
+[libdispatch]:http://en.wikipedia.org/wiki/Libdispatch
+[HawtDispatch]:http://hawtdispatch.fusesource.org/
+[gcd]:http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090903.pdf
+
+
+The thread model allows Apollo to reach very high levels of scaleability and
+efficiency, but it places a huge restriction on the developer: all the tasks
+it executes must be non-blocking and ideally lock-free and wait free. This
+means that the previous ActiveMQ broker architecture had to go through a
+major overhaul. All synchronous broker interfaces had to be changed
+so that they would instead return results via asynchronous callbacks.
+
+### Scala 2.8 Implementation
+
+Even though Apollo started as a fork of ActiveMQ 5.x, the new reactor design
+restrictions required major changes from the network IO handling, to the
+flow control design, all the way to the Store interfaces. Scala provided a
+much more concise way to express callbacks, namely by it's support for
+partial functions and closures.
+
+### Protocol Agnostic
+
+ActiveMQ has supported multiple protocols for many years, but under the
+covers what it's doing is converting all the protocols to use the
+[OpenWire][] messaging protocol. Naturally, this approach is not optimal if
+you want to efficiently support other protocols and not be limited by what
+OpenWire can support.
+
+[OpenWire]:http://activemq.apache.org/openwire.html
+
+The Apollo server is much more modular and protocol agnostic. All protocols
+are equal and are built as a plugin to the the broker which just make use of
+exposed broker services for routing, flow control, queueing services etc.
+For example, this means that messages will be persisted in a Store in the
+original protocol's encoding. There is no protocol conversion occurring
+under the covers unless it is required.
+
+### REST Based Management
+
+ActiveMQ choose to exposed it's management interfaces via JMX. JMX was a
+natural choice since ActiveMQ is Java based, but JMX has a couple of
+serious limitations:
+
+* No cross language support
+* Not scaleable for exposing many objects. Registering and unregistering
+  management objects in JMX can become a bottle neck.
+* Rich data types are hard to expose
+
+Apollo exposes a rich and detailed state of the sever using REST based JSON
+or XML services.
+
+* A management client can easily be implemented in any language.
+* There is very little management overhead since there is no special
+  registration with the management system. The JAX-RS based management web
+  application knows how to navigate the internal structure of a broker to
+  access all the need status and statistics.
 
---- name:content pipeline:tags,textile
-
-h1. Getting Started:
-
-Some pointers to get you going with the prototype:
-
-It is located in the activemq sandbox at: "https://svn.apache.org/repos/asf/activemq/sandbox/activemq-flow":https://svn.apache.org/repos/asf/activemq/sandbox/activemq-flow
-
-Running some testcases:
-
-When running these testcases you should use the -server jvm argument:
-
-# *activemq-queue module org.apache.activemq.flow.MockBrokerTest*. This is a good starting
point for looking at some of the flow control, dispatcher and queue modules. It is a very
basic MockBroker which uses a lightweight proto-buf based protocol. You should feel free to
play around with some of the hardcoded options in the test (e.g. ptp=true, tcp=true, threadsPerDispatcher
etc).
-# *activemq-openwire module org.apache.activemq.broker.SharedQueuePerfTest.* This test does
performance testing against the SharedQueue implementation and is a good place to start looking
at queue persistence and the CursoredQueue. It employs openwire messages with using network
connecitons. Check out *org.apache.activemq.broker.BrokerQueueStore* which currently hardcodes
the queue sizes; you can change DEFAULT_SHARED_QUEUE_PAGING_THRESHOLD and the associated persistence
policy to play around with paging.
-# *activemq-all module org.apache.activemq.broker.openwire.OpenWireBrokerTest*. This test
uses the full blown broker, adds in a tcp transport layert and provides options for persistence
and durable subscriptions (albeit asynchronous at the moment). It extends *org.apache.activemq.broker.BrokerTest*
in the activemq-broker module which has some additional hard coded options to play around
with. Again refer to *org.apache.activemq.broker.BrokerQueueStore* to mess around with queue
sizes.
-
-
-h1. Flow Control
-
-The activemq-flow package is meant to be a standalone module that deals generically with
Resources and Flow's of elements that flow through and between them. Each resource creates
a FlowController for each of it's Flows which is assigned a corresponding FlowLimiter. As
elements (e.g. messages) pass from one resource to another they are passed through the downstream
resource's FlowController which updates its Limiter. If propagation of an element from one
resource to another causes the downstream limiter to become throttled the associated FlowController
will block the source of the element. The flow module is used heavily by the rest of the core
for memory and disk management.
-
-* _Memory Mangement:_ Memory is manged based on the resources in play \-\- the usage is computed
by summing of the space allocated to each of the resources' limiters. This strategy intentionally
avoids a centralized memory limit which leads to complicated logic to track when a centralized
limiter needs to be decremented and avoids contention between multiple resources/threads accessing
the limiter and also reduces the potential for memory limiter related deadlocks. However,
it should be noted that this approach doesn't preclude implementing centralized limiters in
the future.
-* _Flow Control:_ As messages propagate from one resource A to another B, then if A overflows
B's limit, B will block A and A can't release it's limiter space until B unblocks it. This
allowance for overflow into downstream resources is a key concept in flow control performance
and ease of use. Provided that the upstream resource has already accounted for the message's
memory it can freely overflow any downstream limiter providing it reserves space from elements
that caused overflow.
-* _Threading Model:_ Note that as a message propagates from A to B, that the general contract
is that A won't release it's memory if B blocks it during the course of dispatch. This means
that it is not safe to perform a thread handoff during dispatch between two resources since
the thread dispatching A relies on the message making it to B (so that B can block it) prior
to A completing dispatch.
-* _Management/Visibility:_ Another intended use of the activemq-flow module is to assist
in visibility e.g. provide an underlying map of resources that can be exposed via tooling
to see the relationships between sources and sinks of messages and to find bottlenecks ...
this aspect has been downplayed for now as we have been focusing more on the queueing/memory
management model in the prototype, but eventually the flow package itself will provide a handy
way of providing visibility in the system particularly in terms of finding performance bottlenecks.
-
-*FlowResource (FlowSink and FlowSource):* A container for FlowControllers providing some
lifecycle related logic. The base resource class handles interaction/registration with the
FlowManager (below).
-
-*FlowManager:* Registry for Flow's and FlowResources. The manager will provide some hooks
into system visibility. As mentioned above this aspect has been downplayed somewhat for the
present time.
-
-*FlowController*: Wraps a FlowLimiter and actually implements block/resume logic
-
-*FlowLimiter*: Defines the limits enforced by a FlowController. Currently the package has
size based limiter implementations, but eventually should also support other common limiter
types such as rate based limiters. The limiter's are also extended at other points in the
broker (for example implementing a protocol based WindowLimiter). It is also likely that we
would want to introduce CompositeLimiters to combine various limiter types.
-
-*Flow*: The concept of a flow is not used very heavily right now. But a Flow defines the
stream of elements that can be blocked. In general the prototype creates a single flow per
resource, but in the future a source may break it's elements down into more granular flows
on which downstream sinks may block it. One case where this is anticipated as being useful
is in networks of brokers where-in it may be desirable to partition messages into more granular
flows (e.g based on producer or destination) to avoid blocking the broker-broker connection
uncessarily).
-
-h1. Dispatcher / Threading Model
-
-The dispatcher package is basically a smart thread pool \-\- at the new broker core almost
everything should be driven by a dispatcher to keep thread count down and scalability up.
-
-    * Components in the core create DispatchContexts which they use to request dispatch via
a Dispatcher. The dispatch attempts to be smart about grouping together dispatch contexts
that interact with one another to reduce contended synchronization. For example if we have
a producer->queue->consumer scenario each with their own dispatch context, the dispatcher
attempts to group them all on the same thread to avoid contention.
-    * The Dispatcher is priority based which in conjunction with partitioned queues assists
in dispatching higher priority messages
-    * The Dispatcher also support creation of simple Executors that operate on the dispatch
threads.
-    * Supports timer callbacks.
-
-h1. Persistence Store
-
-KahaDB based. As it stands now there is a single worker thread / queue that drives the store
impl (BrokerDatabase).
-
-    * Like other resources, the BrokerDatabase employs a flow controller so as elements are
added to the queue they may block the source (e.g. a producer) if the configured memory limit
is exceeded.
-    * The BrokerDatabase allows events to be delayed. This is at a key optimization for persistent
delivery (in conjunction with the CursoredQueue implementation). When a persistent message
is placed on a queue with consumers that are keeping up, it is placed on the DB queue with
a flush delay. If the consumer, acknowledged the message prior to the delay expiring it is
removed from the queue and doesn't have to hit the disk.
-
-The approach of a single worker thread driving the store is still under debate. It's pros
are that it reduces contention at the store layer, allows batching of several operations into
a single disk sync, and simplifies ordering of interrelated db operations. The major downside
is that it doesn't allow the store to leverage all cpus for encoding decoding work. The store
implementation itself is not yet complete and needs more work.
-
-h1. Queues
-
-The activemq-queue module contains basic queue implementations and a Subscription interfaces.
It relies heavily on activemq-flow and activemq-dispatcher modules. The intent is to allow
the queue module to be used by both the broker and the client. The queue module has 3 basic
queue types:
-* Exclusive Queue: Only one subscription is attached to the queue (e.g. topic subscriber
or durable)
-* Share Queue: A load balanced queue where messages are loadbalanced across multiple consumers.
-* Relay: Like a queue but simply a pass through (useful in cases where it doesn't make sense
to buffer up messages but where you still want to a FlowController to throttle sources.
-
-In addition the queue module defines partitioned queues to allow segmenting messages based
on arbitrary criteria (more below). It also has priority based implementations built in.
-
-
-h2. CursoredQueue
-
-The hope is to use the CursoredQueue as the single persistence mechanism for messages, and
serves as the basis for other queue types that require persistence. It supports browsing and
expiration.
-It the case of SharedQueues, Durables, Transactions and even non durables that wish to offload
messages to the store when the consumer is too slow.
-
-* Transactions: usecase is to hold messages in memory until commit time, spooling to disk
if transaction memory limit is reached.
-* SharedQueue store queue messages.
-* DurableQueue store durable messsages
-* TopicSubscription when configured to
-
-It can operate in a couple of different modes:
-
-* Keep all elements in memory and throttle sources to the memory limit \-\- persisting only
elements whose QoS level dictates it.
-* Two paging modes otherwise. Offload the message itself but keep a placeholder in memory
(increases performance), or page out place holders to allow for very large queue backlogs
(where the placeholders themselves become a memory burden).
-
-There is still a fair amount of policy work /customization to be done here with respect to
paging queues, particular with respect to slow or disconnected subscribers:
-
-* Expunge Policy: When to discard messages (if ever)
-* Handling of temporary bursts: In general if subscribers can keep up with the publishers
it is best to keep messages in memory instead of paging them out, however, for the case of
a temporary burst paging to disk can be appropriate
-* When paging out page out a reduced rate or as fast as possible?
-* Disconnected Subscriber (no subs on queue or disconnected durable): throttle the rate at
which producers send messages to the store to improve recovery time?
-* Other usecases/scenarios?
-
-
-h2. Partitioning of queues
-
-We've also introduced the concept of partitioned queue in which a single queue can be partitioned
to increase parallelization of queue processing. Additionally:
-
-* Priority based partitions allow dispatch of higher priority messages first.
-* Can be used for JMSXGroupID (not implemented yet)
-* For clustering connections partitioning can be used to create parallel independently limited
message flows between brokers (so if there is a slow consumer at the other side only only
the streams of messages being sent to it will be blocked).
-
-h1. Work in Progress
-
-There are still some architectural details that need to get ironed out.  See the "TODO Items":{relocatable:/todo.html}
for a more detailed list.

Modified: activemq/sandbox/activemq-apollo-actor/apollo-website/src/index.page
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/apollo-website/src/index.page?rev=961238&r1=961237&r2=961238&view=diff
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/apollo-website/src/index.page (original)
+++ activemq/sandbox/activemq-apollo-actor/apollo-website/src/index.page Wed Jul  7 04:41:34
2010
@@ -27,12 +27,29 @@ sort_info: 1
 
 # {project_name:}
 
-Eventually this could be flushed out so that it can become the project website.  For now
we are using webgen to keep
-track of notes we make along the way.
+## Synopsis
 
+[Apollo][] is a forked and stripped down Apache [ActiveMQ][] message
+broker. It is focused on simplicity, stability and scalability.
+
+[Apollo]:http://github.com/chirino/activemq-apollo
+[ActiveMQ]:http://activemq.apache.org/
+
+## Implemented Features
+
+* Topic style message routing
+* Queue style message routing
+* Persistent Messages
+* Message paging/swapping
+  queue sizes
+* Message Selectors
+* Queue Browsers
+* REST based management
+* [Stomp](http://stomp.github.com/) Protocol Support
 
 ## Project Notes:
 
+ * [Performance and Scaling]({relocatable:/performance-scaling.html})
  * [Architecture]({relocatable:/architecture.html})
- * [TODO Items]({relocatable:/todo.html})
  * [Module Organization]({relocatable:/module-organization.html})
+ * [TODO Items]({relocatable:/todo.html})

Modified: activemq/sandbox/activemq-apollo-actor/apollo-website/src/metainfo
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/apollo-website/src/metainfo?rev=961238&r1=961237&r2=961238&view=diff
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/apollo-website/src/metainfo (original)
+++ activemq/sandbox/activemq-apollo-actor/apollo-website/src/metainfo Wed Jul  7 04:41:34
2010
@@ -31,7 +31,7 @@
   # pages using the {var:} syntax.
   # -------------------------------------------------------------------
   project_name: "Apollo"
-  project_slogan: "The message broker focused on simplicity, stability and scalability"
+  project_slogan: "Advanced messaging simplifed"
   description: "Apollo, the message broker focused on simplicity, stability and scalability"
   keywords: "ActiveMQ Apollo message broker simplicity stability scalability"
   project_logo: /images/project-logo.png
\ No newline at end of file

Modified: activemq/sandbox/activemq-apollo-actor/apollo-website/src/mirgration-guide.page
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/apollo-website/src/mirgration-guide.page?rev=961238&r1=961237&r2=961238&view=diff
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/apollo-website/src/mirgration-guide.page (original)
+++ activemq/sandbox/activemq-apollo-actor/apollo-website/src/mirgration-guide.page Wed Jul
 7 04:41:34 2010
@@ -15,33 +15,6 @@
 # limitations under the License.
 
 title: Migration Guide
-in_menu: true
---- name:overview pipeline:haml,tags
-
-%h1 Migration Guide
-
-Lets keep track of all differences that end users will notice between ActiveMQ 5 and ActiveMQ
6.
-
 --- name:content pipeline:textile
 
-h3. vm:// Transport URI format change:
-
-The VM transport configuration is much simpler now.  It now only supports 2 options:
-
-  * broker: Set to a broker Factory URI used to configure the embedded broker
-  * create: If the embedded broker should get created if it does not yet exist.  Defaults
to true.
-
-Example: _vm://localhost?broker=jaxb:conf/activemq.xml&create=true_
-  
-Furthermore, the host name part of the URI does not need to the broker name anymore.  It
is just 
-the name of the 'pipe' to the broker.  The first VMTransport associate a pipe name with a
broker
-wins in cases where you have multiple VM client connections trying to crate different broker

-configurations with the same pipe name.  For example you may get non determinist results
if:
-
-bq. Client on Thread 1 tries to create a connection to 
-    _vm://localhost?broker=jaxb:conf/brokerA.xml_ 
-    and concurrently Client on Thread 2 tries to create a connection to 
-    _vm://localhost?broker=jaxb:conf/brokerB.xml_
-
-As the first thread to associate the "localhost" pipe name to a broker instance will win
and the 
-other thread will connect to the first threads broker.
\ No newline at end of file
+TODO
\ No newline at end of file

Modified: activemq/sandbox/activemq-apollo-actor/apollo-website/src/module-organization.page
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/apollo-website/src/module-organization.page?rev=961238&r1=961237&r2=961238&view=diff
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/apollo-website/src/module-organization.page (original)
+++ activemq/sandbox/activemq-apollo-actor/apollo-website/src/module-organization.page Wed
Jul  7 04:41:34 2010
@@ -24,7 +24,8 @@ title: Module Organization
 
 ## Updating
 
-You can regenerate the above graph by running the following commands at the project root:
+You can regenerate the above graph by running the following commands at the
+project root:
 
     mvn -P graph graph:reactor -Dhide-transitive=true -Dhide-external=true -Dgraph.label=
-Dhide-version=true -Dhide-group-id=true -Dhide-type=true
     cp target/reactor-graph.png apollo-website/src/images/module-deps-graph.png

Modified: activemq/sandbox/activemq-apollo-actor/apollo-website/src/network-design.page
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/apollo-website/src/network-design.page?rev=961238&r1=961237&r2=961238&view=diff
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/apollo-website/src/network-design.page (original)
+++ activemq/sandbox/activemq-apollo-actor/apollo-website/src/network-design.page Wed Jul
 7 04:41:34 2010
@@ -3,8 +3,6 @@
 # subsidiaries or affiliates.  All rights reserved.
 
 title: Network Design
-in_menu: true
-sort_info: 2
 --- name:overview pipeline:haml,tags
 
 %h1 A Scaleable Network Design

Modified: activemq/sandbox/activemq-apollo-actor/apollo-website/src/privacy-policy.page
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/apollo-website/src/privacy-policy.page?rev=961238&r1=961237&r2=961238&view=diff
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/apollo-website/src/privacy-policy.page (original)
+++ activemq/sandbox/activemq-apollo-actor/apollo-website/src/privacy-policy.page Wed Jul
 7 04:41:34 2010
@@ -17,16 +17,28 @@
 title: Privacy Policy
 --- pipeline:textile,tags
 
-Information about your use of this website is collected using server access logs and a tracking
cookie. The collected information consists of the following:
+Information about your use of this website is collected using server access
+logs and a tracking cookie. The collected information consists of the
+following:
 
-  # The IP address from which you access the website;
-  # The type of browser and operating system you use to access our site;
-  # The date and time you access our site;
-  # The pages you visit; and
-  # The addresses of pages from where you followed a link to our site.
+* The IP address from which you access the website
+* The type of browser and operating system you use to access our site
+* The date and time you access our site
+* The pages you visit
+* The addresses of pages from where you followed a link to our site
 
-Part of this information is gathered using a tracking cookie set by the [Google Analytics|http://www.google.com/analytics/]
service and handled by Google as described in their [privacy policy|http://www.google.com/privacy.html].
See your browser documentation for instructions on how to disable the cookie if you prefer
not to share this data with Google.
+Part of this information is gathered using a tracking cookie set by the
+[Google Analytics][] service and handled by Google as described in their
+[privacy policy][]. See your browser documentation for instructions on how to
+disable the cookie if you prefer not to share this data with Google.
 
-We use the gathered information to help us make our site more useful to visitors and to better
understand how and when our site is used. We do not track or collect personally identifiable
information or associate gathered data with any personally identifying information from other
sources.
+We use the gathered information to help us make our site more useful to
+visitors and to better understand how and when our site is used. We do not
+track or collect personally identifiable information or associate gathered
+data with any personally identifying information from other sources.
 
-By using this website, you consent to the collection of this data in the manner and for the
purpose described above.
+By using this website, you consent to the collection of this data in the
+manner and for the purpose described above.
+
+[Google Analytics]:http://www.google.com/analytics/
+[privacy policy]:http://www.google.com/privacy.html

Modified: activemq/sandbox/activemq-apollo-actor/apollo-website/src/styles/impact/css/site.css
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/apollo-website/src/styles/impact/css/site.css?rev=961238&r1=961237&r2=961238&view=diff
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/apollo-website/src/styles/impact/css/site.css (original)
+++ activemq/sandbox/activemq-apollo-actor/apollo-website/src/styles/impact/css/site.css Wed
Jul  7 04:41:34 2010
@@ -16,6 +16,12 @@ h1, h2, h3, h4, h5, h6 {
     color: #993333;
 }
 
+h2 {
+  border-top: 4px solid #E0E0E0 !important;
+  margin-top: 1.5em !important;
+  padding-top: 0.5em !important;
+}
+
 p { margin-bottom:0px; }
 
 a {

Modified: activemq/sandbox/activemq-apollo-actor/apollo-website/src/todo.page
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/apollo-website/src/todo.page?rev=961238&r1=961237&r2=961238&view=diff
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/apollo-website/src/todo.page (original)
+++ activemq/sandbox/activemq-apollo-actor/apollo-website/src/todo.page Wed Jul  7 04:41:34
2010
@@ -15,7 +15,6 @@
 # limitations under the License.
 
 title: TODO
-in_menu: true
 --- name:overview pipeline:haml,tags
 
 %h1 The TODO list
@@ -24,6 +23,10 @@ Stuff that still needs to get done.  Con
 
 --- name:content pipeline:textile
 
+h2. Networks / Federations
+
+Based on this [Network Design]({relocatable:/network-design.html})
+
 h2. Transactions:
 
 * Should be backed by cursored queue

Modified: activemq/sandbox/activemq-apollo-actor/readme.md
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/readme.md?rev=961238&r1=961237&r2=961238&view=diff
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/readme.md (original)
+++ activemq/sandbox/activemq-apollo-actor/readme.md Wed Jul  7 04:41:34 2010
@@ -11,20 +11,13 @@ broker. It is focused on simplicity, sta
 ## Implemented Features
 
 * Topic style message routing
-
 * Queue style message routing
-
 * Persistent Messages
-
 * Message swapping: moves message out of memory to support unlimited
   queue sizes
-
 * Message Selectors
-
 * Queue Browsers
-
 * REST based management
-
 * [Stomp](http://stomp.github.com/) Protocol Support
 
 ## Performance
@@ -36,35 +29,26 @@ useful for getting an idea of it's perfo
 The benchmark clients access the server as follows:
 
 * Clients and server run on the same machine. 
-
 * Clients access the server using STOMP over TCP. 
-
 * Producers send non-persistent messages
-
 * Messages contain a 20 byte payload 
-
 * Producers do not wait for a broker ack before sending the next message. 
-
 * Consumers use auto ack.
 
 The following benchmark results were run on a Mac Pro with:
 
 * Dual socket 3 ghz Quad-Core Intel Xeon (8 total cores) with 12 MB L2
   cache per processor .
-
 * 8 GB of RAM
 
 ### Queue Cases
 
 * 1 producer sending to 1 consumer via 1 queue can hit rates of 250,000
   messages/second.
-
 * 8 producers sending to 8 consumers via 8 queues can hit rates of 540,000
   messages/second.
-
 * 1 producer sending to 10 consumers via 1 queue can hit rates of 230,000
   messages/second.
-
 * 10 producers sending to 1 consumers via 1 queue can hit rates of 280,000
   messages/second.
 
@@ -74,10 +58,8 @@ Rates reported are the total consumer ra
 
 * 1 producer sending to 1 consumer via 1 topic can hit a rates of 420,000
   messages/second.
-
 * 8 producers sending to 8 consumers via 8 topics can hit rates of 810,000
   messages/second.
-
 * 10 producer sending to 10 consumers via 1 topic can hit rates of
   1,3000,000 messages/second.
 
@@ -87,9 +69,7 @@ There are many different extreme ways th
 Some folks like to:
 
 * connect a large number of clients.
-
 * hold a large number of messages in their queues.  
-
 * move around large messages.
 
 Apollo aims to support all those usage scenarios.
@@ -205,17 +185,14 @@ natural choice since ActiveMQ is Java ba
 serious limitations:
 
 * No cross language support
-
 * Not scaleable for exposing many objects. Registering and unregistering
   management objects in JMX can become a bottle neck.
-
 * Rich data types are hard to expose
 
 Apollo exposes a rich and detailed state of the sever using REST based JSON
 or XML services.
 
 * A management client can easily be implemented in any language.
-
 * There is very little management overhead since there is no special
   registration with the management system. The JAX-RS based management web
   application knows how to navigate the internal structure of a broker to



Mime
View raw message