Unexpected XML Response

[juan gomez]

We experienced a similar issue, while using jdbc-outbound endpoints. The workaround was not functional in our case.
<br /><br />
We then opted to use a instead of the message processor and the MULE_CORRELATION_ID for the messages was maintained in that case.
<br /><br />
Should the message processor keep the MULE_CORRELATION_ID intact or was this intended behavior?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Fake David Dossot]

The second sentence above is very hard to understand: it seems words are missing.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[juan gomez]

We experienced a similar issue, while using jdbc-outbound endpoints. The workaround was not functional in our case.
<br /><br />
We then opted to use a 'processor-chain' instead of the 'all' message processor and the MULE_CORRELATION_ID for the messages was maintained in that case.
<br /><br />
Should the message processor keep the MULE_CORRELATION_ID intact or was this intended behavior?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[juan gomez]

Should the 'all' message processor keep the MULE_CORRELATION_ID intact or was this the intended behavior?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Fake David Dossot]

The <code>&lt;all&gt;</code> message processor shouldn't affect the message properties but the endpoints it contains may do so.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[John Woodward]

Well, the endpoints, being jdbc:outbound-endpoints doing an insert of data to our database aren't affecting the message. We saw this easily enough by having just a single endpoint without the "all" message processor --- the correlator worked just fine in that case. Having 2 endpoints in the all, though, causes issues that the correlation information is gone when the all processor completes.
<br /><br />
I tried the workaround given above, as it sounded like the exact same situation we had (the workaround being to stuff the correlation information into a session-level message attribute, and then pull that out of the session and push it back into the message resulting from the "all" message processor), but ... that didn't work. With some judicious logging, you could see that any new session attributes in this flow were gone. Curiously, session attributes we added in another flow were still present, though (for various reasons, we start the mule processing with a flow that adds a timestamp as a session attribute).
<br /><br />
Juan and I ran through a number of test cases and eventually settled on using a processor chain instead of "all", but it's still a workaround to the issue of the "all" processor not maintaining correlation information. The processor chain only works in our particular case ... where we have the 2 jdbc outbound endpoints.
<br /><br />
We're rather curious about whether the "all" processor should be scrubbing the correlation information. It looks like the schema supports turning on some correlation behavior, but that's completely undocumented and doesn't appear to be functional in any case (yeah, we tried all the allowable settings).

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[David Dossot]

There is nothing in the "all" implementation that wipes out the session on purpose so that must be a side effect of the message cloning that happens before sending to each of the MPs inside it.
<br /><br />
I'm wondering if you need a processor chain at all: can't you just put the MPs that are in the chain directly in the flow and have the same result?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[John Woodward]

In retrospect, you're probably right that we don't need a processor chain but could just list the 2 endpoints and be done with it.
<br /><br />
As for the "all" ... if it were the endpoints that were affecting the correlation info, it wouldn't matter if they were in the "all" or not, but it does. The session info itself, though ... hmmm... have to think about that case, but I wouldn't expect that an endpoint would clear some aspects of the session. It really struck me as strange that the older session attributes I set were still present, but not the new ones directly in that flow.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[David Dossot]

Indeed this doesn't feel like a feature IMO.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email