On 03/17/2011 12:40 PM, Aki Yoshida wrote:
...
1. Retry Behavior at Source Sequence
Currently, there is no maximum retry count and a retry can run forever
if the message is not acknowledged. I would like to introduce an
optional parameter to configure the maximum retry count. If the retry
count reaches this limit, the status of the message can be set to
undelivered or failed. The failed message can be removed from the
retransmission queue and may only be retried after a manual
intervention.
I don't see any way of making this work as stated, since it would
violate the WS-RM specification (which doesn't allow the sender to
arbitrarily decide to drop individual messages). What *could* be done is
to add maximum retry count and maximum retry times, and abort the whole
sequence if these are exceeded. But you'd need to somehow notify the
client when this occurs. Any thoughts on that?
...
3. Sequence caching in memory
Currently, the source and destination sequences are loaded into memory
from the storage at the startup of the endpoints. This may consume an
increased amount of unnecessary memory if many of the sequences are
not active while not yet expired. This situation may happen when
several conditions are satisfied, for example, when the sequence
termination policy configured to limit the number of unacknowledged
messages per sequence, occurring frequent transmission errors, and
messages generated at a high rate.
WS-RM implementations *should* terminate the sequence when they're done
using it, so a big build up of unexpired sequences should not occur. But
I'd think the memory usage by these sequences is relatively
insignificant anyway. Have you seen cases where there are really large
numbers of sequences open and this becomes a problem?
- Dennis
