Applying response transformers when you shouldn't

[solidjb]

Currently we are experiencing a problem where a bad message is blowing up in a response transformer.  We have the following service configuration:

<service name="request-service">
      <inbound>
        <jms:inbound-endpoint
            connector-ref="jmsConnectorWMQ"
            address="${jms.inbound.endpoint}?method=processRequest"
            synchronous="true"
            transformer-refs="Jms2Obj RequestTransformer"
            responseTransformer-refs="ResponseTransformer MessagePropertiesTransformer Obj2Jms">
           <jms:transaction action="ALWAYS_BEGIN"/>
        </jms:inbound-endpoint>
      </inbound>
      <component>
        <interceptor-stack ref="InterceptorStack"/>
        <spring-object bean="service"/>
      </component>
        <custom-exception-strategy class="test.mule.exception.ExceptionStrategy">
            <commit-transaction exception-pattern="**"/>
        </custom-exception-strategy>
    </service>

(We use the jms reply to header to get our response instead of using a configured outbound endpoint.)

The response transformers are called on the message that is being sent to the replyTo queue.  When the ResponseTransformer throws an exception, our custom exception strategy is called appropriately, and it can perform whatever actions it would like (in our example, it sends an error message out on the replyTo queue).  Mule handles both the message result and the exception correctly and combines them into one mule message containing both a good payload and an exception payload.  This combined mule message is passed back up the call stack until we back to the MultiConsumerJmsMessageReceiver.  In line 373 of AbstractMessageReceiver (which MultiConsumerJmsMessageReceiver extends), the response transformers are called again unconditionally.  I assume this is done, because there are situations when the MessageReceiver will actually send a reply (ie. TcpMessagereceiver.handleResults sends out messages that would have been transformed in the unconditional responseTransformers call)  Unfortunately, because the call to the response transformers is made unconditionally, we re-call the response transformers, and in our case, we blow up again.  In the case of things blowing up this time, there is no exception strategy to deal gracefully with the exception.  Also, because we are in the middle of a transaction when we blow up, the transaction catches the exception and rolls back the correct message that we sent out on the reply to queue.

I think that the way to fix this is to move the applyTransformers call out of AbstractMessageReceiver and move the call down into the specific implementations only if that implementation is going to send out a response.  Otherwise you will continue to transform messages for no reason as they will not be sent out.

I'm using Mule 2.2.1.

JB

"I like work: it fascinates me.  I can sit and look at it for hours."
— Jerome K. Jerome

[David Dossot-3]

Can't you set up this transformer to ignore payload types it can't chew?

D.

On Wed, Oct 21, 2009 at 7:12 AM, Baker,Jonathan <bakerj@...> wrote:

Currently we are experiencing a problem where a bad message is blowing up in a response transformer.  We have the following service configuration:

<service name="request-service">
      <inbound>
        <jms:inbound-endpoint
            connector-ref="jmsConnectorWMQ"
            address="${jms.inbound.endpoint}?method=processRequest"
            synchronous="true"
            transformer-refs="Jms2Obj RequestTransformer"
            responseTransformer-refs="ResponseTransformer MessagePropertiesTransformer Obj2Jms">
           <jms:transaction action="ALWAYS_BEGIN"/>
        </jms:inbound-endpoint>
      </inbound>
      <component>
        <interceptor-stack ref="InterceptorStack"/>
        <spring-object bean="service"/>
      </component>
        <custom-exception-strategy class="test.mule.exception.ExceptionStrategy">
            <commit-transaction exception-pattern="**"/>
        </custom-exception-strategy>
    </service>

(We use the jms reply to header to get our response instead of using a configured outbound endpoint.)

The response transformers are called on the message that is being sent to the replyTo queue.  When the ResponseTransformer throws an exception, our custom exception strategy is called appropriately, and it can perform whatever actions it would like (in our example, it sends an error message out on the replyTo queue).  Mule handles both the message result and the exception correctly and combines them into one mule message containing both a good payload and an exception payload.  This combined mule message is passed back up the call stack until we back to the MultiConsumerJmsMessageReceiver.  In line 373 of AbstractMessageReceiver (which MultiConsumerJmsMessageReceiver extends), the response transformers are called again unconditionally.  I assume this is done, because there are situations when the MessageReceiver will actually send a reply (ie. TcpMessagereceiver.handleResults sends out messages that would have been transformed in the unconditional responseTransformers call)  Unfortunately, because the call to the response transformers is made unconditionally, we re-call the response transformers, and in our case, we blow up again.  In the case of things blowing up this time, there is no exception strategy to deal gracefully with the exception.  Also, because we are in the middle of a transaction when we blow up, the transaction catches the exception and rolls back the correct message that we sent out on the reply to queue.

I think that the way to fix this is to move the applyTransformers call out of AbstractMessageReceiver and move the call down into the specific implementations only if that implementation is going to send out a response.  Otherwise you will continue to transform messages for no reason as they will not be sent out.

I'm using Mule 2.2.1.

JB

"I like work: it fascinates me.  I can sit and look at it for hours."
— Jerome K. Jerome

[Andrew Perepelytsya]

I think there's an easier fix - have you tried disableTemporaryReplyToDestinations?

Andrew

[solidjb]

The type is correct, there is a problem with the data.

 

JB

"I like work: it fascinates me.  I can sit and look at it for hours."
— Jerome K. Jerome

 

---

From: David Dossot [mailto:ddossot@...]
Sent: Wednesday, October 21, 2009 10:47 AM
To: user@...
Subject: Re: [mule-user] Applying response transformers when you shouldn't

Can't you set up this transformer to ignore payload types it can't chew?

D.

On Wed, Oct 21, 2009 at 7:12 AM, Baker,Jonathan <bakerj@...> wrote:

Currently we are experiencing a problem where a bad message is blowing up in a response transformer.  We have the following service configuration:

<service name="request-service">
      <inbound>
        <jms:inbound-endpoint
            connector-ref="jmsConnectorWMQ"
            address="${jms.inbound.endpoint}?method=processRequest"
            synchronous="true"
            transformer-refs="Jms2Obj RequestTransformer"
            responseTransformer-refs="ResponseTransformer MessagePropertiesTransformer Obj2Jms">
           <jms:transaction action="ALWAYS_BEGIN"/>
        </jms:inbound-endpoint>
      </inbound>
      <component>
        <interceptor-stack ref="InterceptorStack"/>
        <spring-object bean="service"/>
      </component>
        <custom-exception-strategy class="test.mule.exception.ExceptionStrategy">
            <commit-transaction exception-pattern="**"/>
        </custom-exception-strategy>
    </service>

(We use the jms reply to header to get our response instead of using a configured outbound endpoint.)

The response transformers are called on the message that is being sent to the replyTo queue.  When the ResponseTransformer throws an exception, our custom exception strategy is called appropriately, and it can perform whatever actions it would like (in our example, it sends an error message out on the replyTo queue).  Mule handles both the message result and the exception correctly and combines them into one mule message containing both a good payload and an exception payload.  This combined mule message is passed back up the call stack until we back to the MultiConsumerJmsMessageReceiver.  In line 373 of AbstractMessageReceiver (which MultiConsumerJmsMessageReceiver extends), the response transformers are called again unconditionally.  I assume this is done, because there are situations when the MessageReceiver will actually send a reply (ie. TcpMessagereceiver.handleResults sends out messages that would have been transformed in the unconditional responseTransformers call)  Unfortunately, because the call to the response transformers is made unconditionally, we re-call the response transformers, and in our case, we blow up again.  In the case of things blowing up this time, there is no exception strategy to deal gracefully with the exception.  Also, because we are in the middle of a transaction when we blow up, the transaction catches the exception and rolls back the correct message that we sent out on the reply to queue.

I think that the way to fix this is to move the applyTransformers call out of AbstractMessageReceiver and move the call down into the specific implementations only if that implementation is going to send out a response.  Otherwise you will continue to transform messages for no reason as they will not be sent out.

I'm using Mule 2.2.1.

JB

"I like work: it fascinates me.  I can sit and look at it for hours."
— Jerome K. Jerome

[solidjb]

I am not sure how that will fix the problem, as the flow through mule is all working correctly.  Every thing responds as expected excetpwhen we get to the call to applyResponseTransformers after the reply has already gone out. 

 

I verified that commenting out this one line fixes the problem, but it doesn't seem appropriate to just comment it out, the transformers should still be run if the message receiver is going to reply, they just shouldn't be run unconditionally even if we aren't sending out a reply.

 

JB

"I like work: it fascinates me.  I can sit and look at it for hours."
— Jerome K. Jerome

 

---

From: Andrew Perepelytsya [mailto:aperepel@...]
Sent: Wednesday, October 21, 2009 10:53 AM
To: user@...
Subject: Re: [mule-user] Applying response transformers when you shouldn't

I think there's an easier fix - have you tried disableTemporaryReplyToDestinations?

Andrew