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 2009/06/11 17:31:30 UTC

svn commit: r783816 - in /activemq/sandbox/activemq-flow/webgen/src: architecture.page images/ images/project-logo.gif todo.page

Author: chirino
Date: Thu Jun 11 15:31:29 2009
New Revision: 783816

URL: http://svn.apache.org/viewvc?rev=783816&view=rev
Log:
moved the todos to the todo page.

Added:
    activemq/sandbox/activemq-flow/webgen/src/images/
    activemq/sandbox/activemq-flow/webgen/src/images/project-logo.gif   (with props)
Modified:
    activemq/sandbox/activemq-flow/webgen/src/architecture.page
    activemq/sandbox/activemq-flow/webgen/src/todo.page

Modified: activemq/sandbox/activemq-flow/webgen/src/architecture.page
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-flow/webgen/src/architecture.page?rev=783816&r1=783815&r2=783816&view=diff
==============================================================================
--- activemq/sandbox/activemq-flow/webgen/src/architecture.page (original)
+++ activemq/sandbox/activemq-flow/webgen/src/architecture.page Thu Jun 11 15:31:29 2009
@@ -16,18 +16,19 @@
 
 title: Architectural Overview
 in_menu: true
---- pipeline:textile
+--- name:overview pipeline:haml,tags
 
-h1. Overview
+%h1 {project_name:} Architecture
 
-This page explores some of the details around core components. 
+Explore the core components that make this next generation Broker work.
 
+--- 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}
+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:
 
@@ -117,36 +118,6 @@
 * 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
+h1. Work in Progress
 
-
-h2. Transactions:
-
-* Should be backed by cursored queue
-
-h2. Large Message Support:
-
-* There are some stubs in the Store interface for this, but basically for large messages we should be able to stage them to disk, and when given to a consumer chunk the payload out to keep memory low. The cursored queue will need to be updated to handle this.
-
-h2. Protocol Support
-
-Lots of work still to be done here\!
-
-* Protocol Handlers are there for OpenWire and STOMP, and we'll want to add proto buf as well.
-* Do we convert things to a common message format on arrival or keep them in their native format doing transforms on the fly?
-* Common interfaces for Connection/Session/*Consumer for the broker to interact with?
-* Threading model ... We should probably come up with a good abstract base class for the protocol handlers that helps to provide a threading model that will make synchronization between I/O events (exceptions etc), protocol events and message dispatch). 
-
-h2. Replication:
-
-* This should be handled by KahaDB replication
-* Still need to think about replication of non persistent messages, though ...e.g. messages that are never saved to disk but only replicated to peers.
-* Recovery time. Keep state fairly hot to achieve fast failover time, we'll want to keep optimizations in this area in mind (basically messages that are in memory on the active broker are kept in memory on the standby as well).
-
-h2. General Interface cleanliness
-
-A fair amount of clean up work needs to be done to clean up and harden interfaces in the prototype. 
-
-h2. Testing
-
-As much of the work to date has been largely experimental in nature, testing up to now has focussed mainly on end to end type performance tests, but more unit testing and functional testing of edge cases such as slow subscriber test etc are needed. 
\ No newline at end of file
+There are still some architectural details that need to get ironed out.  See the "TODO Items":{relocatable:/todo.html} for a more detailed list.

Added: activemq/sandbox/activemq-flow/webgen/src/images/project-logo.gif
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-flow/webgen/src/images/project-logo.gif?rev=783816&view=auto
==============================================================================
Binary file - no diff available.

Propchange: activemq/sandbox/activemq-flow/webgen/src/images/project-logo.gif
------------------------------------------------------------------------------
    svn:mime-type = application/octet-stream

Modified: activemq/sandbox/activemq-flow/webgen/src/todo.page
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-flow/webgen/src/todo.page?rev=783816&r1=783815&r2=783816&view=diff
==============================================================================
--- activemq/sandbox/activemq-flow/webgen/src/todo.page (original)
+++ activemq/sandbox/activemq-flow/webgen/src/todo.page Thu Jun 11 15:31:29 2009
@@ -16,9 +16,49 @@
 
 title: TODO
 in_menu: true
---- pipeline:textile
+--- name:overview pipeline:haml,tags
+
+%h1 The TODO list
+
+Stuff that still needs to get done.  Contributions Welcomed!
+
+--- name:content pipeline:textile
+
+h2. Transactions:
+
+* Should be backed by cursored queue
+
+h2. Large Message Support:
+
+* There are some stubs in the Store interface for this, but basically for large messages we should be able to stage them to disk, and when given to a consumer chunk the payload out to keep memory low. The cursored queue will need to be updated to handle this.
+
+h2. Protocol Support
+
+Lots of work still to be done here\!
+
+* Protocol Handlers are there for OpenWire and STOMP, and we'll want to add proto buf as well.
+* Do we convert things to a common message format on arrival or keep them in their native format doing transforms on the fly?
+* Common interfaces for Connection/Session/*Consumer for the broker to interact with?
+* Threading model ... We should probably come up with a good abstract base class for the protocol handlers that helps to provide a threading model that will make synchronization between I/O events (exceptions etc), protocol events and message dispatch). 
+
+h2. Replication:
+
+* This should be handled by KahaDB replication
+* Still need to think about replication of non persistent messages, though ...e.g. messages that are never saved to disk but only replicated to peers.
+* Recovery time. Keep state fairly hot to achieve fast failover time, we'll want to keep optimizations in this area in mind (basically messages that are in memory on the active broker are kept in memory on the standby as well).
+
+h2. General Interface cleanliness
+
+A fair amount of clean up work needs to be done to clean up and harden interfaces in the prototype. 
+
+h2. Testing
+
+As much of the work to date has been largely experimental in nature, testing up to now has focussed mainly on end to end type performance tests, but more unit testing and functional testing of edge cases such as slow subscriber test etc are needed. 
+
+h1. Misc Tasks
 
-h2. Tasks
 * InactivityMonitor needs to get inserted for OpenWire on the server side of MultiWireFormat negotiation.
 * BIO SSL Transport does not currently pass Client Certificate chain in OpenWire ConnectionInfo command. This used to be done by the SSL transport but this shouldn't have OpenWire dependencies; instead protocol handler should be able to retrieve it from the underlying transport as needed. 
 
+
+