• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 608
  • Last Modified:

exchange pattern

We use mule ESB for file transfers, socket connections, jms. We developed our modules using mule 2.x version at that time and encountered no issues. We have been experimenting lately with mule 3.0 to see if our existing modules will still work. After reading the docs for migrating from 2 - 3 we had to change the synchronous attribute with exchange-pattern with request-response. Everything else remains the same but when i test with the new versin i get an exception that

The endpoint "xservice" is malformed and cannot be parsed. If this is the name of a global endpoint, check the name is correct, that the endpoint exists, and that you are using the correct configuration (eg the "ref" attribute). Note that names on inbound and outbound endpoints cannot be used to send or receive messages; use a named global endpoint instead.

This used to work earlier fine but when upgrading i get that error.

0
Micheal_Male
Asked:
Micheal_Male
  • 5
  • 3
1 Solution
 
Jim CakalicSenior Developer/ArchitectCommented:
Can you post the relevant segment(s) of your configuration?
0
 
Jim CakalicSenior Developer/ArchitectCommented:
I haven't used Mule 3 (yet) but I have used Mule 2 for a significantly sized project. After reading the Mule 3 configuration docs I have a couple questions/suggestions ...

First, you said you are using the file, jms and socket (by which I assume you mean tcp) transports. Each transport has its own default and allowed message exchange patterns.

file is only one-way
jms is only one-way
tcp is one-way or request-response with default request-response
My thought is that if you are configuring file and jms connectors or endpoints (which at least jms used to allow synchronous="true") with exchange-pattern="request-response" then that would be an error in the Mule 3 configuration. I wouldn't be surprised if this resulted in a parse exception instead of some more useful indication that an invalid value was supplied for the endpoint. If this is the case, try removing the exchange-pattern attribute from those configuration elements (since you can't configure for anything other than one-way anyway).

Perhaps for jms they may have decided to remove support for the request-response pattern (at least in community edition) because it was very problematic - at least in our experience as we wanted essentially a one-way or in-only pattern but needed to declare the endpoints synchronous so we could use XA transactions across the message flow. The requreiment that the component return a response was messy to configure away. For file endpoints the attribute wouldn't have made any sense but might have been allowed and ignored.
0
 
Micheal_MaleAuthor Commented:
Thanks for the detailed explanation. The one which i am testing is related to tcp.  This is the same config we used in mule 2.x with the only difference is that it had synchronous="true" which is replaced with exchange-pattern as per the docs. So it should work but apparently it does not and just giving the global endpoint exception really does not make any sense and is hard to debug to see where the error is.

<inbound>
<inbound-endpoint name="xService" address="vm://xService.endpoint" exchange-pattern="request-response"/>
</inbound>
</echo-component>
<outbound>
<pass-through-router>
<outbound-endpoint ref="testServer">
</outbound-endpoint>
</pass-through-router>
</outbound>
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
Jim CakalicSenior Developer/ArchitectCommented:
Have you tried configuring with the transport-specific namespace?

<inbound>
    <vm:inbound-endpoint name="xService" path="xService.endpoint" exchange-pattern="request-response"/>
</inbound>
</echo-component>
<outbound>
    <pass-through-router>
        <outbound-endpoint ref="testServer">
        </outbound-endpoint>
    </pass-through-router>
</outbound> 

Open in new window

0
 
Micheal_MaleAuthor Commented:
Yes i did tried that and still got the global endpoint exception.
0
 
Micheal_MaleAuthor Commented:
I also saw a bug posted on mulesoft for this version but that is related to smtp.

http://mule.1045714.n5.nabble.com/MalformedEndpointException-when-configuring-SMTP-with-URL-encoded-character-td3308646.html 
0
 
Micheal_MaleAuthor Commented:
Upgrading to the newer version did solve my problem.
0
 
Micheal_MaleAuthor Commented:
Upgraded to the newer version 3.0.1
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

  • 5
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now