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 >
