Re: [ebxmlms-develop] Non-compliance found, and other changes requested

[Gait B. <gai...@ti...>]

mine in red :-)

Thanks, merry XMas and happy new year to all,=20
Gait
  ----- Original Message -----=20
  From: Patrick Yee=20
  To: ebx...@li...=20
  Sent: Friday, December 20, 2002 4:30 AM
  Subject: Re: [ebxmlms-develop] Non-compliance found, and other changes =
requested


  Hi Gait,

  My comment in blue.

  Thanks & regards, -Patrick

    The third issue is related to DuplicateElimination.
    I set up two Monitors talking to each other. One Monitor repeatedly =
sends a message with a fixed message id and time stamp, and duplicate =
elimination (DE) turned on. However, all messages are received by the =
other Monitor. After adding some additional logging to =
MessageServer.hasReceived, I found that the record for the corresponding =
message is never retrieved from the database. I also noticed that =
hasReceived queries against a set of application context parameters and =
the message id, which I believe to be wrong, at least for DE. For DE, =
checking should be done on the parameters passed in from the message, =
since we want to check for duplication of the message itself.

    Do you mean there is a case that we have 2 messages, having the same =
message ID but with different application context, and we would wrongly =
missed the DE? We think this is not logical as 2 messages having the =
same message ID should be identical. To this end, we are considering a =
more stringent approach: not to allow application to send out 2 messages =
having the same message ID. We suggest, if application level retry is =
needed, a new message ID should be used. Only MSH can send out 2 =
messages with the same message ID when doing MSH level retry. It is not =
legal for the application to "reuse" message ID in any case.
    Resending a message with the same ID is a feature of retries, and =
the DuplicateElimination was introduced so that when one MSH retries a =
message because something went wrong with the handshaking on the =
response, the receiving MSH can suppress the duplicates. The reason I =
suggest using the AC parameters from the message is related to the fact =
that the MSH supports wildcards. Between the first message and the =
duplicate, the configuration may have changed such that a different AC =
picks up the message (e.g. a new listener registered with a more =
specific AC). Even though the message is a duplicate, it will still be =
delivered to both the new, and the old listener. That's why DE should be =
based only on parameters from the message.

    Did I miss something in the configuration that might break proper DE =
handling? Could it be that it does not work because I'm looping back on =
the same MSH, and the sending Monitor actually updates the DB in between =
calls?

    Yes you are right, this is the problem only when you are looping =
back on the same MSH. If the 2 applications are connected to 2 different =
MSHs, this problem will not occur. This is a bug that the sender =
application will trigger MSH to update the DB in every try. We would =
file this bug and fix it in the future.
    OK, that reduces it to a nuisance, should be fixed in V1.0 :-)