cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <>
Subject Re: WS-RM client callback property
Date Tue, 18 Feb 2014 20:36:40 GMT
Hi Aki,

I included the information in messageAcknowledge so that the callback 
could be used either as per-invocation or shared, depending on what the 
user wants. The simple implementation I mentioned, just counting how 
many messages have been sent and acknowledged, would be intended for 
shared use.

   - Dennis

On 02/19/2014 12:58 AM, Aki Yoshida wrote:
> hi Dennis,
> getting the sequenceId and messageNum to the client sounds good.
> the callback remain simple, yet the client can perform more advanced
> tasks using this information supplied to the callback.
> but why do we have seqId/msgNum for messageAcknowledge? Wasn't your
> original callback idea assume a per-invocation object and it has now
> become a shared callback object? I thought a per-invocation object is
> more practical for the client but I am not sure now, as a shared one
> seems to be also practical for some cases.
> regards, aki
> 2014-02-17 22:13 GMT+01:00 Dennis Sosnoski <>:
>> I guess the question is whether we want to duplicate the JMX functionality.
>> My thought was to keep this callback really simple, but still supply the
>> essential information (basically, that the message has made it through to
>> the far end) to the client. I suppose it would be easy enough to add another
>> method to supply information at the start of the sending process, too:
>> interface RMCallback {
>>      void messageAccepted(String seqId, long msgNum);
>>      void messageAcknowledged(String seqId, long msgNum);
>> }
>> This way they'd have all the information to identify the message, and if
>> they want to take full control over the process they can use this
>> information through the JMX interface. How does that sound to you?
>> I can still supply the simple counting implementation that just lets the
>> client check whether all the messages have been acknowledged yet.
>>    - Dennis
>> On 02/17/2014 10:14 PM, Aki Yoshida wrote:
>>> Hi Dennis,
>>> right. It would be useful to make some information conveniently
>>> available to the calling client.
>>> But we might want to provide a callback not just for getting the ack
>>> status but for getting various other WS-RM information such as the
>>> sequence ID, message number and even some control over the messages
>>> and sequences it created?
>>> Or I am not sure if we should give the sequence info back in the
>>> callback and let the client use jmx to get more info and exercise
>>> control over the sequence?
>>> regards, aki
>>> 2014-02-14 8:15 GMT+01:00 Dennis Sosnoski <>:
>>>> It's important for clients using WS-RM to know when all the messages
>>>> they've
>>>> sent have been acknowledged, because it's not safe for them to terminate
>>>> until this has been done. Right now we're able to use JMX to monitor
>>>> WS-ReliableMessaging operation and see when messages are acknowledged.
>>>> But
>>>> this seems overly complex to me, and I'm thinking of adding a simpler
>>>> callback mechanism to make it easier.
>>>> The basic interface would be something like:
>>>> interface AcknowledgementCallback {
>>>>       void messageAcknowledged();
>>>> }
>>>> I could also supply an AcknowledgementCountingCallback implementation
>>>> which
>>>> would just count how many times it's been called, and define a waitFor(n,
>>>> timeout) method on this which would wait until that many messages had
>>>> been
>>>> acknowledged (or until timed out). That way an instance could be set as a
>>>> client property, and the user could just count how many messages they'd
>>>> sent
>>>> and when they're done call the waitFor() method to make sure they'd all
>>>> been
>>>> received before the application terminates.
>>>> Any objections or better ideas?
>>>> Thanks,
>>>>     - Dennis
>>>> Dennis M. Sosnoski
>>>> Java Web Services Consulting <>
>>>> CXF and Web Services Security Training
>>>> <>
>>>> Web Services Jump-Start <>

View raw message