cxf-dev mailing list archives

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

I didn't mean to violate the WS-RM spec in the protocol level. I meant
exactly the option that you say it could. These non-deliverable
messages need to be marked as failed and we need an option to manually
intervene with the next step, either restart them again or terminate
them permanently. The client can find out using the current callback
API to determine whether the message has been delivered or not. We can
provide some JMS beans to check the statuses and to provide this
manual intervension option.

>> ...
>> 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?

The current policy configuraiton allows restricting the number of
unacknowledged messages per sequence. So if there are massive
transmission errors ocurring, while the client continues to send
messages, sequences may build up. I haven't observed this problem but
this could become a possible risk in a real productive environment. We
may also need an option to block the client call or throw an exception
if the sequence or message backlog is building up rapidly and
consuming too much resources.

Regards, Aki

View raw message