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

Support the Synchronous to Asynchronous scenario

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

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 2.0.2
  • Fix Version/s: 2.0 ITR7, 2.1.0, 2.2.2 (EE only), 2.2.4 (EE only)
  • Component/s: Core: Configuration
  • Labels:
    None
  • User impact:
    Low
  • Affects Docs:
    Yes
  • Similar Issues:
    None

Description

http://ricston.com/blog/?p=37

It is simple to convert an asynchronous message flow to a synchronous one by setting the synchronous property of the endpoint to true. All flows from that endpoint onwards will be synchronous.

In order to convert a synchronous message flow into an asynchronous one, you need to either use remote-sync (imposing the overhead of keeping the event context around) or use a wiretap inbound router and wire tap the message to your asynchronous endpoint. Your original message flow remains as-is so this is not really a conversion of sync to async.

This is a funky solution to a simple problem. IMHO, Mule should support this pattern more explicitly, perhaps by just allowing to set the sync property of an endpoint to false and doing the right thing. Example of an API that can achieve this: the endpoint's synchronous property can be a java.lang.Boolean with three possible values: true - force synchronous from now on; false - force asynchronous; null - use whatever is the current mode (get it from the event).

The responses would be propagated by the remote-sync / sync endpoints and will be dropped if they reach async endpoint (a DEBUG or INFO log message would be good.)

Issue Links

blocks

Bug - A problem which impairs or prevents the functions of the product. MULE-4617 JMSReplyToHandler tries to send to JMS endpoint synchronously (creating temp destination) rather than dispatching

  • 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.
is blocked by

Bug - A problem which impairs or prevents the functions of the product. MULE-4620 MULE_REMOTE_SYNC_PROPERTY should not be used to determine outbound endpoint synchronicity

  • 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

Improvement - An improvement or enhancement to an existing feature or task. MULE-3767 Review the need for remoteSync attribute

  • Critical - Crashes, loss of data, severe memory leak.
  • Reopened - This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved.

Improvement - An improvement or enhancement to an existing feature or task. MULE-3759 Remove the synchronous param from the Router.route API methods

  • 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.

Bug - A problem which impairs or prevents the functions of the product. MULE-4608 Loanbroker example not working

  • Blocker - Blocks development and/or testing work, production could not run.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. MULE-3759 Remove the synchronous param from the Router.route API methods

  • 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.
Show 1 more links (1 relates to)

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
  • Transitions
  • Commits
  • Source
  • Builds
Hide
Permalink
Ross Mason added a comment - 03/Oct/08 02:58 PM

This behaviour has been implemented for the 2.1 release

Show
Ross Mason added a comment - 03/Oct/08 02:58 PM This behaviour has been implemented for the 2.1 release
Hide
Permalink
Ross Mason added a comment - 05/Oct/08 06:45 AM

Thanks for reporting. fixed here: http://fisheye.codehaus.org/changelog/mule/?cs=12886.

Documentation for this issue is being tracked here: MULE-3765

Show
Ross Mason added a comment - 05/Oct/08 06:45 AM Thanks for reporting. fixed here: http://fisheye.codehaus.org/changelog/mule/?cs=12886. Documentation for this issue is being tracked here: MULE-3765
Hide
Permalink
Daniel Feist added a comment - 19/Nov/09 02:14 PM - edited

This scenario does not work when outbound endpoint is JMS this is because JMS implementation uses AbstractMessageDispatcher.returnResponse(MuleEvent) to determine if it should set up a temporary reply queue to receive a response or not. This method still uses the REMOTE_SYNC message property.

Whenever the inbound endpoint is sync the REMOTE_SYNC property gets set on the message for some reason in org.mule.transport.AbstractMessageReceiver.routeMessage(MuleMessage, Transaction, boolean, OutputStream)

A workaround is to use the disableTemporaryDestinations property.

This also affects the scenario where inbound is sync and there is a async replyTo.

Show
Daniel Feist added a comment - 19/Nov/09 02:14 PM - edited This scenario does not work when outbound endpoint is JMS this is because JMS implementation uses AbstractMessageDispatcher.returnResponse(MuleEvent) to determine if it should set up a temporary reply queue to receive a response or not. This method still uses the REMOTE_SYNC message property. Whenever the inbound endpoint is sync the REMOTE_SYNC property gets set on the message for some reason in org.mule.transport.AbstractMessageReceiver.routeMessage(MuleMessage, Transaction, boolean, OutputStream) A workaround is to use the disableTemporaryDestinations property. This also affects the scenario where inbound is sync and there is a async replyTo.
Hide
Permalink
Daniel Feist added a comment - 27/Nov/09 01:12 PM

This now works for JMS now that MULE-4620 is fixed and so this issue can be closed again.

Show
Daniel Feist added a comment - 27/Nov/09 01:12 PM This now works for JMS now that MULE-4620 is fixed and so this issue can be closed again.
Hide
Permalink
Daniel Feist added a comment - 27/Nov/09 01:13 PM

Note: JMS sync->async is only fully supported as from 2.2.4, previous to this version you will need to use the disableTemporaryDestinations property is you don't want the jms dispatcher waiting for a response that will never arrive.

Show
Daniel Feist added a comment - 27/Nov/09 01:13 PM Note: JMS sync->async is only fully supported as from 2.2.4, previous to this version you will need to use the disableTemporaryDestinations property is you don't want the jms dispatcher waiting for a response that will never arrive.

People

  • Assignee:
    Daniel Feist
    Reporter:
    Dimitar Dimitrov
Vote (1)
Watch (0)

Dates

  • Created:
    30/Jul/08 04:39 AM
    Updated:
    27/Nov/09 01:13 PM
    Resolved:
    27/Nov/09 01:12 PM

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.