good synposis. maybe we should disable send() when using VM queues since you're not going to get a response from the queue anyway.
I did some further digging around the message scribbling and found the following -
1. Message rewriting has the biggest impact on performance (yourkit shows that way too much time is spent writing property maps)
2. we use RequestContext.safeRewriteEvent for writing response message properties when performing req/res messaging
3. We often use RequestContext.unsafeRewriteEvent as a safe-guard in case the message changed
4. When using send() we often return the original message when there is no result from the send operation.
All of this is throwback from Mule 1.x. We have fixed the route causes for doing these kinds of things in Mule 2.x except for one (request/response handling)
WRT Request Response handing (point 2), right now we 'merge' request and response messages which is confusing at best. The reason this is done is because you some times need properties on the request message to be available after you get a response back. I think there are two ways of handling this -
- Have a specialisation of MuleMessage called RequestResponseMuleMessage that maintains a reference to both the request and the response message and provides interfaces for accessing the request message. This means people will have to check for the message type and cast it, or we make a bigger change to the send() method signature
- Ignore the request message but provide a way let users configure which properties they want to be carried over from the request message to the response message. This could be done using a PropertyScope i.e. Session could be used, but not ideal. Or we could add a new scope for this purpose.
Point 3 should not be necessary any longer since Message payloads are not immutable as they were in Mule 1.x. The rewrite action is the most expensive. I believe we should only have to create a DefaultMuleMessage once for each request. This would improve performance.
Point 4. We would need to wrap a 'null' return into a NullPayload when using MuleClient.send() since we never return a null right now. This is partly be cause if anything does go wrong we can attach an exception payload to the return message. I think it would be less disruptive if we kept this behaviour.
IMO one of the biggest enabler of message scribbling is the VM transport because it allows the mule to "copy" the message over two threads. The other is our handling of request/response message flows and sync message flow in VM (which Dan points out).
Bug
Reopened
Major
good synposis. maybe we should disable send() when using VM queues since you're not going to get a response from the queue anyway.
I did some further digging around the message scribbling and found the following -
1. Message rewriting has the biggest impact on performance (yourkit shows that way too much time is spent writing property maps)
2. we use RequestContext.safeRewriteEvent for writing response message properties when performing req/res messaging
3. We often use RequestContext.unsafeRewriteEvent as a safe-guard in case the message changed
4. When using send() we often return the original message when there is no result from the send operation.
All of this is throwback from Mule 1.x. We have fixed the route causes for doing these kinds of things in Mule 2.x except for one (request/response handling)
WRT Request Response handing (point 2), right now we 'merge' request and response messages which is confusing at best. The reason this is done is because you some times need properties on the request message to be available after you get a response back. I think there are two ways of handling this -
Point 3 should not be necessary any longer since Message payloads are not immutable as they were in Mule 1.x. The rewrite action is the most expensive. I believe we should only have to create a DefaultMuleMessage once for each request. This would improve performance.
Point 4. We would need to wrap a 'null' return into a NullPayload when using MuleClient.send() since we never return a null right now. This is partly be cause if anything does go wrong we can attach an exception payload to the return message. I think it would be less disruptive if we kept this behaviour.
IMO one of the biggest enabler of message scribbling is the VM transport because it allows the mule to "copy" the message over two threads. The other is our handling of request/response message flows and sync message flow in VM (which Dan points out).
- Have a specialisation of MuleMessage called RequestResponseMuleMessage that maintains a reference to both the request and the response message and provides interfaces for accessing the request message. This means people will have to check for the message type and cast it, or we make a bigger change to the send() method signature
- Ignore the request message but provide a way let users configure which properties they want to be carried over from the request message to the response message. This could be done using a PropertyScope i.e. Session could be used, but not ideal. Or we could add a new scope for this purpose.
Point 3 should not be necessary any longer since Message payloads are not immutable as they were in Mule 1.x. The rewrite action is the most expensive. I believe we should only have to create a DefaultMuleMessage once for each request. This would improve performance. Point 4. We would need to wrap a 'null' return into a NullPayload when using MuleClient.send() since we never return a null right now. This is partly be cause if anything does go wrong we can attach an exception payload to the return message. I think it would be less disruptive if we kept this behaviour. IMO one of the biggest enabler of message scribbling is the VM transport because it allows the mule to "copy" the message over two threads. The other is our handling of request/response message flows and sync message flow in VM (which Dan points out).