| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQJMS2007 / mqrc: 2009 -error from .send(), but msg in Q |
« View previous topic :: View next topic » |
| Author |
Message
|
| mvic |
 Posted: Fri Jan 20, 2006 8:34 am Post subject: |
 |
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
OK I'll stop defending a scheme that I dreamt up in 1/2 hour 
There are obviously issues with the original design, but I think it is useful insofar as it provides an audit trail mechanism.
I think we are agreed (??) that reconciliation or fault-tolerant error handling is possible only if there is an audit trail.
What better audit trail mechanisms are there? (Remember the audit trail must have one and only one entry for each message that was put to the app queue...) |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Jan 20, 2006 8:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I think I was clear that an audit trail as you described it, is not necessarily the only tool for reconciliation.
If messages have unique business identifiers, and downstream processing logs those identifiers, then as long as we know the ids in the in doubt messages, we can resolve the doubt without an audit trail as you described.
In ESB-like systems I've built, I put a message archiving service at the front door of the ESB - everything that came in was archived. Then all my ESB infrastructure merely logged what it had done with messages and logged the unique IDs of the messages that it had handled. And the downstream processes could actually discard messages if they thought that they could not ever be processed.
Messages that needed to be replayed for whatever reason were recovered from the archive and resent at the front door, with new unique IDs (but correlated to the old ID's).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Jan 20, 2006 9:07 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| jefflowrey wrote: |
I think I was clear that an audit trail as you described it, is not necessarily the only tool for reconciliation.
... |
There must be an audit trail of some description, surely?
I note you go on to mention "downstream processing logs", "message archiving service at the front door of the ESB", logging, and an archive.
In the terminology I am used to, these are other ways of saying "audit trail". 
A quick question on your experience of setting this up: what does a client do in a system like the one you've described if, because of a network outage, there is some doubt (eg. a 2009 from put or commit) over whether the message was successfully placed on the queue at the server? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jan 20, 2006 10:42 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes, there must be an audit trail of some type or another. But your description was distinct in that, presumably, every message producer was copying all messages to two queues.
The behavior of a client outside the ESB system I was describing would do exactly what I suggested. Write a log to a file or something that contained enough information about both the exception that occurred and the business data involved to be able to restore the transaction if neccessary, and then retry the connection for a short period of time and then halt.
Inside the ESB system I described, the application could choose to merely record the exception data and unique ids of the message, trusting that the acrhive contained a record of the message.
And the archive system itself would use a two-phase unit of work (and a bindings connection) to ensure that messages were either on the queue or in the database.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
