activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chir...@apache.org
Subject svn commit: r783816 - in /activemq/sandbox/activemq-flow/webgen/src: architecture.page images/ images/project-logo.gif todo.page
Date Thu, 11 Jun 2009 15:31:30 GMT
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.

 
+
+



Mime
View raw message