it looks like there is some complexity in the desired convenient
default behavior

for non-persistence case, it probably makes more sense to switch the
default behavior to terminate the sequence.

but for johns in-order case, the in-ordeing may break when we don't
keep the old persisted sequence and only let the application decide to
terminate the current sequence and start a new one.

So, I am not really convinced of the benefit of changing the default
of terminateOnShutdown=false, but I also don't find a very strong
argument for keeping the current default.

regards, aki


2013/9/3 John Li <[email protected]>:
> hi all,
>
> I would also think it logical that the client by default will sent a
> terminate sequence on normal shutdown since it cleans up the resources. In
> the case that the client crashes unexpectedly it should pick up from where
> it ended.
>
> Regarding relying on maxSequence might cause problems with clients that are
> heavily relying on 'inOrder' delivery. During a pilot we have set this
> sequence to 10 and we have seen that in some cases message 11 was handled
> by the server before message 10. Since inOrder is only working within the
> same sequence and message 11 was sent with a new sequence this seems to be
> 'as designed'. Maybe a bit of topic but wanted to mention this while you
> guys are looking into the terminate sequence.
>
> regards,
> John
>
>
>
> On Mon, Sep 2, 2013 at 11:49 PM, Dennis Sosnoski <[email protected]> wrote:
>
>> On 09/03/2013 02:48 AM, Aki Yoshida wrote:
>>
>>> ...
>>>
>>>
>>> I think, as long as the client either terminates each unused old
>>> sequence or keeps reusing the old sequence, it is well behaved. In
>>> contrast, when the client keeps creating a new sequence and never
>>> terminates those sequences, it's a bad client for himself and for the
>>> communicating server.
>>>
>>
>> That's exactly the situation we have now, in the case where a client is
>> executed without persistent storage. Even with persistent storage, if the
>> client only runs periodically it's a bad practice to keep the same sequence
>> around.
>>
>> Relying on expires is also not a great idea in general, since this is an
>> optional setting that's only controlled by the CXF custom configuration.
>>
>>   - Dennis
>>

Reply via email to