Discussion Points : 2009-07-03
This page captures points to be addressed from a discussion between:
Robery Godfrey (RG)
Marnie McCormack (MM)
Martin Ritchie (MR)
Aidan Skinner (AS)
Use Cases
| ID |
Raised By |
Description |
Status |
Outcome |
| UC-1 |
AS |
Need more details on what the client changes that need to be done, in a new Doc. |
|
|
| UC-2 |
MM |
Use Case 4 Outbound buffers can fill if client is slow. |
Added |
|
Functional Requirements
| ID |
Raised By |
Description |
Status |
Outcome |
| F-1 |
AS |
We are trying to bind all buffers/queues other than the AMQP Queue itself. |
Clarified |
|
| F-2 |
MR |
More clarity : F-6: Transport layer will not block but report full |
Clarified |
|
| F-3 |
MM |
Move Marnie's Points from Compatibility / Migration in to the functional requirements section |
Moved |
|
| F-4 |
MM |
from C/M:3 Ability to switch IO implmentation (mina/new io)/ Run with bounded/unbounded buffers at start up. Not dynamically. |
Added |
|
| F-5 |
RG |
Keep rate statistics rather than logging on the buffers. Capturing data is cheaper than logging directly. |
Added reference to operational logging |
|
| F-6 |
RG |
Average time for sends to complete |
Added to stat gathering req |
|
| F-7 |
ALL |
C/M:4 Logging: Goal is to identify problem area Client/Network/Broker, capturing the size of the buffers will help us identify if it is the client or broker that is the cause. |
Added |
|
| F-8 |
MM |
C/M:5 Bound Changes: Bounding buffers will have impact. A) what size do you set it to. B) What paradigms will need their buffers changed. |
Added sizing documentation to NFRs |
|
| F-9 |
MM |
C/M:5 BC: Buffer should be configurable at in a dynamic context, new connections will have the new buffer size. Existing connections will remain unchanged. |
Added to FRs |
|
| F-10 |
RG |
C/M:5 It is not necessary for the input and output buffers to be the same size. That is the buffer used to receive mesages from a publish(input) and the buffer used to hold messages being sent to the a client(output). |
Added to FRs |
|
Non-Functional Requirements
| ID |
Raised By |
Description |
Status |
Outcome |
| NF-1 |
AS |
4. Current 0-10 client IO has one thread per connection. So not suitable for direct use in broker just now. |
Clarified relevant NFR |
|
| NF-2 |
RG |
5. We need to document current sematics before we can say it will change. |
Added MessageProducer.send() behaviour |
|
| NF-3 |
MR |
(From comments) 5. send() should have option for not blocking. |
Added to FR |
|
Comments
| ID |
Raised By |
Description |
Status |
Outcome |
| C-1 |
RG |
All IO buffers would be affected |
|
|
| C-2 |
RG |
Mina more likely with persistent message |
|
|
| C-3 |
MM |
Break this down in to components. |
Added work breakdown and suggested order |
|
| C-4 |
MM |
Expand all TCP options (TCPNoDelay...) detail what they are being exposed for, setting/reading |
Added complete list |
|
Discussion Points : 2009-07-07
This page captures points to be addressed from a discussion between:
Robery Godfrey (RG)
Marnie McCormack (MM)
Martin Ritchie (MR)
Aidan Skinner (AS)
General
| ID |
Raised By |
Description |
Status |
Outcome |
| G-1 |
MM |
Diagrams would help |
|
|
Functional Requirements
| ID |
Raised By |
Description |
Status |
Outcome |
| F-11 |
MM |
F-8,9,10 : Need to be reworked to be in 3rd person |
|
|
Overview of Design
| ID |
Raised By |
Description |
Status |
Outcome |
| O-1 |
ALL |
O-4 : Capture the impact of removing the Job Queue/Limiting. The implications of of the changes
perhaps accompanied with statistics showing improved performance.
Client is now exposed to latency, i.e. If broker is impacted then client will see this. |
|
| O-2 |
MR |
o-5 : Expand details of substantive changes |
|
|
Breakdown of work
| ID |
Raised By |
Description |
Status |
Outcome |
| B-1 |
RG |
B-1 : Highlight that the inclusion of QpidByteBuffer will be done as part of common interace creation |
|
|
| B-2 |
MM/RG |
Put BofCP into the BoWork section, higlighting wich parts relate to which task. |
|
|
Testing
| ID |
Raised By |
Description |
Status |
Outcome |
| T-1 |
MM |
Define representative testing platforms, LAN, MAN, WAN, etc |
|
|
