I ran across a problem that does not make any sense to me at all. I have a simple top level service that accepts some inputs, populates a document and publishes it to the broker… nothing fancy at all.
Nevertheless, recently, I realized on the logs and because of some user complaints that the service produced multiple duplicate (???) messages on the broker.
In a first look at the system it appeared that the clients invoking the service had some problems and did it multiple times, and I enabled service audit to troubleshoot this… but a closer look revealed that the actual broker documents had the exact same activation field value… and that made me wonder, why?
The invoked service only publishes 1 document, and this is VISIBLE in the flow (there are no loops, etc…)… but I have several documents coming from that service with the same activation generated by IS.
I think this is impossible according to my knowledge on how the activation field works… actually I re-read the documentation about this I continued with the same opinion.
Did anybody run into something similar?
Other than service auditing how else are are you monitoring that there are duplicate document published - are you using DocTracker, document loggging or some other tool?
Does the audit store contain any errors that relate to the published document?
If on the other hand you are consuming the published document via a trigger - then it is possible that the same broker document is seen a number of times. That is - if the trigger service throws a ISRuntimeError then it is quite possible that the document is held on the queue until the next attempt to retrieve this document or until the trigger retry count is meet.
Thanks for your reply.
I am using wmLogUtil (6.1) to log broker documents. And yes, the documents are consumed by triggers that may raise the transient exception programmatically… are you saying that in this situation the wmLogUtil actually saves several document entries? I was not aware of this; after all raising such an exception should not “create” a new document but only not acknowledge it to the broker, thus taking it not out of the queue.
Nevertheless this is much more than just a logging issue. The actual service that runs via the trigger for the documents was called several times, because the service algorithm eventually notifies someone via email… and this person received duplicate emails.
Unfortunately I did not had the Audit settings turned on for the service that published the original documents, so I cannot prove at this time if the service was invoked multiple times by a client thus making it obvious that was not a problem on our side, but on the client side.
What makes me wonder about this is the existance of documents with the same activation field, and only looking at the service that publishes the document its impossible (according to my understanding of the inner works of this envelope field) to publish 2+ documents in the same service invocation.
Not sure if this applies to you, but are you using models? If no, then this won’t help you.
If yes, check the generated model. I have seen where a service is selected for a model step, then later changed without the first being removed. This applies even if the change was not changing the actual service name, but intended to show updated input/output definitions. The model shows the updated service name in Modeler, but in the generated model, which generates a service for each step, there are 2 invokes, one for each of the services. To avoid this, you need to remove the service attached to the step, then add the new (or updated) service to the step.