You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@activemq.apache.org by ch...@apache.org on 2010/07/07 06:41:35 UTC
svn commit: r961238 - in /activemq/sandbox/activemq-apollo-actor: ./
apollo-website/src/ apollo-website/src/styles/impact/css/
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