JIRA

  • Log In Access more options
    • Online Help
    • GreenHopper Help
    • Agile Answers
    • Use Agile By Default
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What’s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Agile Access more options (Alt+g)
  • Create Issue
  • Mule
  • MULE-4864

Mule exceptions do not halt process execution

  • Agile Board
  • More Actions
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 2.2.5 (EE only), 3.0.0-M2
  • Fix Version/s: 3.0.0-RC3
  • Component/s: Modules: BPM / Rules
  • Labels:
    • 30CE_Review
  • User impact:
    Medium
  • Similar Issues:
    None

Description

When a process sends a Mule message and an exception occurs (e.g. in the service or transformer), this exception gets handled by Mule and does not get "bubbled up" to the process, so the process execution happily continues along, not aware that an exception occurred.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
  • Transitions
  • Commits
  • Source
  • Builds
Hide
Permalink
Travis Carlson added a comment - 04/May/10 04:17 PM

http://fisheye.codehaus.org/changelog/mule/?cs=17173

Show
Travis Carlson added a comment - 04/May/10 04:17 PM http://fisheye.codehaus.org/changelog/mule/?cs=17173
Hide
Permalink
Travis Carlson added a comment - 04/May/10 04:43 PM

The problem is in ProcessMessageReceiver.generateEvent(). If the message is sent via routeMessage() (which is the default behavior), the ExceptionPayload is not set on the response message. Setting allowGlobalDispatcher = true will use MuleClient.send() instead, which does set the ExceptionPayload and makes the test case pass. However, this leads to a concurrency issue under high load which makes the Loanbroker BPM test case fail.

If the concurrency error could be fixed, then I would just remove the routeMessage() and make the send() behavior the default. Maybe we'll get lucky and this will just go away after some of the 3.0 cleanup.

Show
Travis Carlson added a comment - 04/May/10 04:43 PM The problem is in ProcessMessageReceiver.generateEvent(). If the message is sent via routeMessage() (which is the default behavior), the ExceptionPayload is not set on the response message. Setting allowGlobalDispatcher = true will use MuleClient.send() instead, which does set the ExceptionPayload and makes the test case pass. However, this leads to a concurrency issue under high load which makes the Loanbroker BPM test case fail. If the concurrency error could be fixed, then I would just remove the routeMessage() and make the send() behavior the default. Maybe we'll get lucky and this will just go away after some of the 3.0 cleanup.
Hide
Permalink
Mateo Almenta Reca added a comment - 03/Aug/10 06:53 PM - edited

Has this gone away for 3.0 CE?

Show
Mateo Almenta Reca added a comment - 03/Aug/10 06:53 PM - edited Has this gone away for 3.0 CE?
Hide
Permalink
Travis Carlson added a comment - 07/Sep/10 08:05 AM

MuleClient.send() is now the default behavior, "allowGlobalDispatcher" attribute has been removed.

http://fisheye.codehaus.org/changelog/mule/?cs=19390

Show
Travis Carlson added a comment - 07/Sep/10 08:05 AM MuleClient.send() is now the default behavior, "allowGlobalDispatcher" attribute has been removed. http://fisheye.codehaus.org/changelog/mule/?cs=19390

People

  • Assignee:
    Travis Carlson
    Reporter:
    Travis Carlson
Vote (0)
Watch (0)

Dates

  • Created:
    04/May/10 02:35 PM
    Updated:
    07/Sep/10 08:05 AM
    Resolved:
    07/Sep/10 08:05 AM

Agile

  • View on Board
  • Atlassian JIRA (v5.0.7#734-sha1:8ad78a6)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for MuleForge. Try JIRA - bug tracking software for your team.