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 <[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
