1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
|
Key:
F = Functional
PF = Partially Functional
NR = Needs Additional Review
ND = Needs Additional Design
NF = Not Functional
Connection:
variables/configuration:
- reconnect: F, NR, ND
+ reconnect functionality is done and the API semantics provided
are ready for review
+ reconnect policies need to be finished, there is currently
only one hardcoded reconnect policy (retry every three
seconds), we need to define the pre-canned policies that we
want to support and a means to configure them, as well as a
very simple plugin/callback for defining ad-hoc policies
+ need to feed failover exchange into the reconnect policy
+ acks can be lost on reconnect
+ handle reconnect during commit/rollback
- timeout: NF
+ some sort of timeout threshold for killing the connection
methods:
- open/__init__: F, ND
+ need to support kerberos
+ need a better way of supplying various kinds of configuration:
- authentication info
- transport specific configuration options, e.g
- heartbeat
- socket options
- tcp-nodelay
- multiple brokers
- session: F, NR
- connect: F, NR
- disconnect: F, NR
- connected: F, NR
- start: F, NR, ND
+ see comment on Receiver.start
- stop: F, NR, ND
+ see comment on Receiver.start
- close: F, NR, ND
+ currently there is no distinction between a "close" that does
a complete handshake with the remote broker, and a "close"
that reclaims resources, this means that close can fail with
an exception, I don't like this as it is unclear to the user
if there is a responsibility to do further cleanup in this
case
errors:
- ConnectionError: F, NR
+ ConnectError F, NR
+ Disconnected F, NR
- notification of disconnect?
Session:
methods:
- sender: F, NR, ND
+ need to detail address options
+ need to define subject pattern semantics
+ consider providing convenience for sender/receiver caching
- receiver: F, NR, ND
+ need to detail address options
+ need to define filter syntax/semantics
+ consider providing convenience for sender/receiver caching
- acknowledge: F, NR
- reject: NF
- release: NF
- commit: F, NR
- rollback: F, NR
- start: F, NR, ND
+ see comment on Receiver.start
- stop: F, NR, ND
+ see comment on Receiver.start
- fetch: NF
+ this method if added would permit the listener functionality
to be removed as it would become trivial to replicate via user
code
- close: F, ND
+ see comment on Connection.close
errors:
- SessionError: F, NR, ND
+ SendError: F, NR, ND
+ ReceiveError: F, NR, ND
+ should there be fatal/non fatal variants?
Sender:
methods:
- pending: F, NR
- send: F, NR
- sync: F, NR, ND
+ currently this blocks until pending == 0, I'm thinking of
renaming this to wait and adding a slightly richer interface
that would let you wait for something like pending < n
- close: F, NR
errors:
- SendError
+ InsufficientCapacity
+ need specific subhierarchy for certain conditions, e.g. no such queue
Receiver:
methods:
- pending: F, NR
- listen: F, ND
+ see comment on Session.fetch
- fetch: F, NR, ND
+ explicit grant for receiver
+ changing capacity/prefetch to issue credit on ack rather than
fetch return
- start: F, NR, ND
+ when a receiver is "stopped", it is treated as if the receiver
has zero capacity even if the capacity field is set to a non
zero value, this is a mild convenience since you can stop and
then start a receiver without having to remember what the
capacity was before, however it is unclear if this is really
worthwhile since stop/start is entirely equivalent to setting
capacity to a zero/non-zero value
- stop: F, NR, ND
+ see comment on Receiver.start
- sync/wait: NF
- close: F, NR
errors:
- ReceiveError
+ Empty
+ need specific subhierarchy for certain conditions, e.g. no such queue
Message:
- standard message properties: F, NR, ND
- map messages: F, NR
+ needs interop testing: NF
+ needs java impl: NF
- list messages: F, NR, NI
+ needs interop testing: NF
+ needs java impl: NF
- boxed types: NF
Address:
- syntax: F, NR
- subject related changes, e.g. allowing patterns on both ends: NF, ND
- creating/deleting queues/exchanges
+ need to handle cleanup of temp queues/topics: NF
+ passthrough options for creating exchanges/queues: NF
- integration with java: NF
- queue browsing: NF
- temporary queues: NF
- xquery: NF
Testing:
- stress/soak testing for async: NF
- stress/soak testing for reconnect: NF
- interop testing: NF
- multi session and multi connection client tests: NF
Documentation:
- api level docs largely present but need updating and elaboration
- tutorial: NF
Examples:
- drain: F, NR
- spout: F, NR
- server: F, NR
- client: NF
- other examples, e.g. async?
Miscellaneous:
- standard ping-like (drain/spout) utilities for all clients: NF
|
