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
share
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
Hi Dennis,
This would be a great improvement. From the field there are concerns about
the fact that they want to have hard prove that the message was delivered
and they want to have their own administration of acknowledgement states.
Of course they should rely on the protocol but in most cases the
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 ano
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 ove
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 t
