[#MULE-1321] The MULE_METHOD_PROPERTY is not being set when dispatching a message

Mule

The MULE_METHOD_PROPERTY is not being set when dispatching a message

Created: 18/Jan/07 09:09 AM Updated: 30/Jan/08 11:01 PM

Component/s:

Core: Transports

Affects Version/s:

1.3.3

Fix Version/s:

None

Time Tracking:

Not Specified

Environment:

Win XP, JDK 5

Issue Links:

Block

This issue is blocked by:

~~MULE-893~~ Clarify/reachitect MuleMessage property mutability & handling

Duplicate

This issue is duplicated by:

~~MULE-1410~~ Asynchronous calls fail with TooManySatisfiableMethodsException

Labels:

User impact:

High

Configuration:

« Hide

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE mule-configuration PUBLIC "-//SymphonySoft //DTD mule-configuration XML V1.0//EN"
 "http://mule.mulesource.org/dtds/mule-spring-configuration.dtd">
 
    <mule-configuration id="PF" version="1.0">
         <model name="pReceiver">
              
              <mule-descriptor name="EventReceiver" implementation="org.mule.components.simple.BridgeComponent">
                   <inbound-router>
                        <endpoint address="file://IN">
                             <filter pattern="*.rdf" className="org.mule.providers.file.filters.FilenameWildcardFilter">
                                  <properties>
                                       <property name="pollingFrequency" value="3000" />
                                  </properties>
                             </filter>
                        </endpoint>
                   </inbound-router>
                   <outbound-router>
                        <router className="org.mule.routing.outbound.OutboundPassThroughRouter">
                             <endpoint address="vm://persister?method=bye" />
                        </router>
                   </outbound-router>
              </mule-descriptor>

              <mule-descriptor name="test" implementation="no.fast.mule.components.TestComponent">
                   <inbound-router>
                        <endpoint address="vm://persister" synchronous="true"/>
                   </inbound-router>
                   <properties>
                        <property name="MULE_SERVICE_METHOD" value="bye" />
                   </properties>
              </mule-descriptor>
         </model>
</mule-configuration>

Description

« Hide

This issue is related to the following user-list entry: http://permalink.gmane.org/gmane.comp.java.mule.user/7567

Jan-Olav Eide wrote:

I have narrowed the configuration down to the simplest possible that still fails.

This configuration simply polls a directory for files with an .rdf extension. The contents of the file is routed to a component that prints the message out. This should now be easy to reproduce for others on 1.3.3

The component with two identical signatures is simply this:

package no.fast.mule.components;

public class TestComponent {

public void hello(String msg) { System.out.println("Hello " + msg); }

public void bye(String msg) { System.out.println("Bye bye " + msg); }
}

On investigation, I realised that the MULE_METHOD_PROPERTY is not being set on the message when the dispatch is used. It however succeeds when the send is used.

All

Comments

Work Log

Change History

Transitions

FishEye

Sort Order:

[ Permlink | « Hide ]

Marie Claire Rizzo added a comment - 18/Jan/07 10:10 AM

Upon further intestigation the problem seems to be coming from the MuleSession. The method ProcessResonse discards the MULE_METHOD_PROPERTY and this consequently blows everything up.

[ Permlink | « Hide ]

Marie Claire Rizzo added a comment - 19/Jan/07 03:27 AM

This looks like a threading problem with the asynchronous message flow.

When debugging/tracing the code, everything works fine. The TooManySatidfiableMethodsError seems to be cropping up whenever the ProcessResponse method is being executed before the DynamicEntryPoint has the time to find the correct entry point.

[ Permlink | « Hide ]

Holger Hoffstaette added a comment - 19/Jan/07 03:43 AM

Thank you very much for tracing through - this is exactly what I had in mind when I asked Jan-Olav to try synchronous. The problem is the removal of the property "in flight" and the only way to fix this is by completely redesigning the state handling of the message properties. As far as I can see there is no simple fix for this.

[ Permlink | « Hide ]

Jan-Olav Eide added a comment - 19/Jan/07 03:55 AM

Would my patch that looks for the method name as part of he MULE_ENDPOINT property if none is found in the MULE_METHOD_PROPERTY be useful, or would that have unfortunate side-effects ?

[ Permlink | « Hide ]

Holger Hoffstaette added a comment - 19/Jan/07 04:36 AM

Jan-Olav: it might help in some (or maybe even many) cases but I'd rather fix the root cause; not everything goes through Dynamic(or Callable)EntryPoints. We already had this on our list of "things to redesign". However I don't know all the details myself.

[ Permlink | « Hide ]

Holger Hoffstaette added a comment - 19/Jan/07 04:38 AM

Btw "mange takk" for your patience; I know what Fast does and how Mule might fit in with your work. I'd love to help better but there's only so much I can do.

[ Permlink | « Hide ]

Andrew Perepelytsya added a comment - 29/Apr/07 03:58 PM

That is definitely not going into 1.4

[ Permlink | « Hide ]

Dirk Olmes added a comment - 30/Jan/08 11:01 PM

descoping from 1.4.4 release