cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <>
Subject Re: Adding more controls to the current WS-RM component
Date Thu, 17 Mar 2011 00:16:19 GMT
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

View raw message