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-4821

Exception message sent twice to the outbound endpoint defined in the exception strategy

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

Details

  • Type: Patch submission Patch submission
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Duplicate
  • Affects Version/s: 2.2.1, 3.0.0-M1, 3.0.0-M2
  • Fix Version/s: Bug Backlog
  • Component/s: Core: Exception Handling
  • Labels:
    None
  • Environment:

    Windows XP SP3 32bit
    Sun JDK 1.6.0_18
    JBoss AS 5.1.0

  • User impact:
    High
  • Similar Issues:
    None

Description

When an Exception is of type org.mule.api.lifecycle.LifecycleException, an exception message is sent twice to the outbound endpoint defined in the exception strategy.

Hereby the original source:

org.mule.AbstractExceptionListener
...
    public void exceptionThrown(Exception e)
    {
        if (enableNotifications)
        {
            fireNotification(new ExceptionNotification(e));
        }

        logException(e);
        handleTransaction(e);

        Throwable t = getExceptionType(e, RoutingException.class);
        if (t != null)
        {
            RoutingException re = (RoutingException) t;
            handleRoutingException(re.getMuleMessage(), re.getEndpoint(), e);
            return;
        }

        t = getExceptionType(e, MessagingException.class);
        if (t != null)
        {
            MessagingException me = (MessagingException) t;
            handleMessagingException(me.getMuleMessage(), e);
            return;
        }

        t = getExceptionType(e, LifecycleException.class);
        if (t != null)
        {
            LifecycleException le = (LifecycleException) t;
            handleLifecycleException(le.getComponent(), e);
            if (RequestContext.getEventContext() != null)
            {
                handleMessagingException(RequestContext.getEventContext().getMessage(), e);
            }
            else
            {
                logger.info("There is no current event available, routing Null message with the exception");
                handleMessagingException(new DefaultMuleMessage(NullPayload.getInstance(), muleContext), e);
            }
            return;
        }

        handleStandardException(e);
    }
...

That method must be replaced by the following source :

org.mule.AbstractExceptionListener
...
    public void exceptionThrown(Exception e)
    {
        if (enableNotifications)
        {
            fireNotification(new ExceptionNotification(e));
        }

        logException(e);
        handleTransaction(e);

        Throwable t = getExceptionType(e, RoutingException.class);
        if (t != null)
        {
            RoutingException re = (RoutingException) t;
            handleRoutingException(re.getMuleMessage(), re.getEndpoint(), e);
            return;
        }

        t = getExceptionType(e, MessagingException.class);
        if (t != null)
        {
            MessagingException me = (MessagingException) t;
            handleMessagingException(me.getMuleMessage(), e);
            return;
        }

        t = getExceptionType(e, LifecycleException.class);
        if (t != null)
        {
            LifecycleException le = (LifecycleException) t;
            handleLifecycleException(le.getComponent(), e);
//            if (RequestContext.getEventContext() != null)
//            {
//                handleMessagingException(RequestContext.getEventContext().getMessage(), e);
//            }
//            else
//            {
//                logger.info("There is no current event available, routing Null message with the exception");
//                handleMessagingException(new DefaultMuleMessage(NullPayload.getInstance(), muleContext), e);
//            }
            return;
        }

        handleStandardException(e);
    }
...

Please note the commented part.

As a matter of fact, this code is duplicated and already executed when abstract method handleLifecycleException(le.getComponent(), e) is called in the implementation class org.mule.DefaultExceptionStrategy.

org.mule.DefaultExceptionStrategy
...
    public void handleLifecycleException(Object component, Throwable t)
    {
        // Do nothing special here. Overriding implmentations may want alter the
        // behaviour
        handleStandardException(t);
        logger.error("The object that failed was: \n" + ObjectUtils.toString(component, "null"));
    }

    public void handleStandardException(Throwable t)
    {
        handleTransaction(t);
        // Attempt to send the exception details to an endpoint if one is set
        if (RequestContext.getEventContext() != null)
        {
            handleMessagingException(RequestContext.getEventContext().getMessage(), t);
        }
        else
        {
            logger.info("There is no current event available, routing Null message with the exception");
            handleMessagingException(new DefaultMuleMessage(NullPayload.getInstance(), muleContext), t);
        }
    }
...

Issue Links

duplicates

Bug - A problem which impairs or prevents the functions of the product. MULE-4960 The AbstractExceptionListener handles the LifecycleException twice

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Patch submission - User code to be reviewed and incorporated into the product. MULE-4840 Exception message sent twice to the outbound endpoint defined in the exception strategy

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

  • All
  • Comments
  • Work Log
  • History
  • Activity
  • Transitions
  • Commits
  • Source
  • Builds
There are no comments yet on this issue.

People

  • Assignee:
    devteam@mulesource.com devteam@mulesource.com
    Reporter:
    Bertrand Gillis
Vote (2)
Watch (3)

Dates

  • Created:
    30/Mar/10 07:40 AM
    Updated:
    06/Dec/10 09:09 AM
    Resolved:
    18/Oct/10 02:24 PM

Time Tracking

Estimated:
5m
Original Estimate - 5 minutes
Remaining:
5m
Remaining Estimate - 5 minutes
Logged:
Not Specified
Time Spent - Not Specified

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.