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

[Patrick Y. <kc...@ce...>]

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.

  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.