cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <...@sosnoski.com>
Subject Re: Changing WS-RM default to terminate on shutdown
Date Sat, 07 Sep 2013 00:43:44 GMT
I think one argument in favor of a change is that anyone wanting to use 
persistence has to use a configuration file to set this up, and if they 
want to keep sequences open on normal shutdown it's just a simple 
addition to this configuration. On the other hand, anyone not using 
persistence does not generally need to use a configuration file, so for 
them the (new) default case of terminate sequence on normal shutdown 
works correctly.

So if there are no other objections I'll change the default for 3.0.

   - Dennis

On 09/06/2013 06:10 AM, Aki Yoshida wrote:
> 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 <john@mycubes.nl>:
>> 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 <dms@sosnoski.com> 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
>>>


Mime
View raw message