2011/3/17 Dennis Sosnoski <d...@sosnoski.com>: > 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
