[#MULE-3318] VmTransactionTestCase failing in 3/4 test cases

Mule

VmTransactionTestCase failing in 3/4 test cases

Created: 08/May/08 09:32 PM Updated: 15/May/08 10:19 PM

Component/s:

Transport: VM

Affects Version/s:

2.0.1

Fix Version/s:

2.0.2

Time Tracking:

Not Specified

File Attachments:

MULE-3318-tobereviewed.patch.txt (4 kB)

Issue Links:

Related

This issue relates to:

~~MULE-2905~~ VM hangs on with transaction

This issue relates to:

~~MULE-3345~~ TransactionTemplate swallows exceptions and returns null instead

Labels:

User impact:

High

Configuration:

« Hide

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesource.org/schema/mule/core/2.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:spring="http://www.springframework.org/schema/beans"
      xmlns:vm="http://www.mulesource.org/schema/mule/vm/2.0"
      xsi:schemaLocation="
                       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
                       http://www.mulesource.org/schema/mule/core/2.0 http://www.mulesource.org/schema/mule/core/2.0/mule.xsd
                       http://www.mulesource.org/schema/mule/vm/2.0 http://www.mulesource.org/schema/mule/vm/2.0/mule-vm.xsd">

    <vm:connector name="vmQueue" queueEvents="true" numberOfConcurrentTransactedReceivers="1"/>
    <vm:connector name="vmNoQueue" queueEvents="false" numberOfConcurrentTransactedReceivers="1"/>

    <spring:bean name="txFactory" class="org.mule.transport.vm.VMTransactionFactory"/>

    <model name="main">
    
        <service name="dispatchService">
            <inbound>
                <vm:inbound-endpoint address="vm://dispatchInQueue" connector-ref="vmQueue">
                    <custom-transaction action="BEGIN_OR_JOIN" factory-ref="txFactory"/>
                </vm:inbound-endpoint>

                <vm:inbound-endpoint address="vm://dispatchInNoQueue" connector-ref="vmNoQueue">
                    <custom-transaction action="BEGIN_OR_JOIN" factory-ref="txFactory"/>
                </vm:inbound-endpoint>
            </inbound>

            <component class="org.mule.transport.vm.functional.VmTransactionTestCase$TestComponent"/>

            <outbound>
                <outbound-pass-through-router>
                    <outbound-endpoint address="vm://out" connector-ref="vmQueue"/>
                </outbound-pass-through-router>
            </outbound>
        </service>

        <service name="sendRequestService">
            <inbound>
                <vm:inbound-endpoint address="vm://sendRequestInQueue" connector-ref="vmQueue">
                    <custom-transaction action="BEGIN_OR_JOIN" factory-ref="txFactory"/>
                </vm:inbound-endpoint>

                <vm:inbound-endpoint address="vm://sendRequestInNoQueue" connector-ref="vmNoQueue">
                    <custom-transaction action="BEGIN_OR_JOIN" factory-ref="txFactory"/>
                </vm:inbound-endpoint>
            </inbound>

            <component class="org.mule.transport.vm.functional.VmTransactionTestCase$TestComponent"/>
        </service>
        
    </model>

</mule>

Show »

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesource.org/schema/mule/core/2.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:spring="http://www.springframework.org/schema/beans"
      xmlns:vm="http://www.mulesource.org/schema/mule/vm/2.0"
      xsi:schemaLocation="
                       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
                       http://www.mulesource.org/schema/mule/core/2.0 http://www.mulesource.org/schema/mule/core/2.0/mule.xsd
                       http://www.mulesource.org/schema/mule/vm/2.0 http://www.mulesource.org/schema/mule/vm/2.0/mule-vm.xsd">

    <vm:connector name="vmQueue" queueEvents="true" numberOfConcurrentTransactedReceivers="1"/>
    <vm:connector name="vmNoQueue" queueEvents="false" numberOfConcurrentTransactedReceivers="1"/>

    <spring:bean name="txFactory" class="org.mule.transport.vm.VMTransactionFactory"/>

    <model name="main">
    
        <service name="dispatchService">
            <inbound>
                <vm:inbound-endpoint address="vm://dispatchInQueue" connector-ref="vmQueue">
                    <custom-transaction action="BEGIN_OR_JOIN" factory-ref="txFactory"/>
                </vm:inbound-endpoint>

                <vm:inbound-endpoint address="vm://dispatchInNoQueue" connector-ref="vmNoQueue">
                    <custom-transaction action="BEGIN_OR_JOIN" factory-ref="txFactory"/>
                </vm:inbound-endpoint>
            </inbound>

            <component class="org.mule.transport.vm.functional.VmTransactionTestCase$TestComponent"/>

            <outbound>
                <outbound-pass-through-router>
                    <outbound-endpoint address="vm://out" connector-ref="vmQueue"/>
                </outbound-pass-through-router>
            </outbound>
        </service>

        <service name="sendRequestService">
            <inbound>
                <vm:inbound-endpoint address="vm://sendRequestInQueue" connector-ref="vmQueue">
                    <custom-transaction action="BEGIN_OR_JOIN" factory-ref="txFactory"/>
                </vm:inbound-endpoint>

                <vm:inbound-endpoint address="vm://sendRequestInNoQueue" connector-ref="vmNoQueue">
                    <custom-transaction action="BEGIN_OR_JOIN" factory-ref="txFactory"/>
                </vm:inbound-endpoint>
            </inbound>

            <component class="org.mule.transport.vm.functional.VmTransactionTestCase$TestComponent"/>
        </service>
        
    </model>

</mule>

Description

« Hide

3 out of 4 tests are failing because the shared TestComponent's test value returns null for TransactionCoordination.getInstance().getTransaction(). An object is always expected. A quick debug shows that the TestComponent instance runs within a separate thread (main) than the code that started the transaction (receiver). I verified this against 1.4 and apparently, the service component is supposed to execute in the same thread in which the transaction actually begun. I suspect that something has fundamentally changed in the underlying design that causes this discrepancy. Note, TransactionCoordination.getInstance().getTransaction() uses ThreadLocal!

All

Comments

Work Log

Change History

Transitions

FishEye

Sort Order:

[ Permlink | « Hide ]

Andrew Perepelytsya added a comment - 09/May/08 10:51 AM

Andreas, could you be more specific about the configs? Maybe the error is there. As for thredlocal - this is how it should work. With TX in place there should be sync execution.

[ Permlink | « Hide ]

Andreas Guenther added a comment - 09/May/08 01:00 PM

Here's the configuration from the deactivated test case. I even ported it over to 1.4 and ran it successfully, just to make sure the changes I recently made didn't break anything in any assumption previously made

My feeling is that the sync part you pointed out does not kick in anymore in 2.0 for some reason.

[ Permlink | « Hide ]

Andreas Guenther added a comment - 10/May/08 05:24 PM

Bumping up to major based on my findings. The actual root cause is as previously suspected a missing transaction instance not being created for the dispatcher and hence its thread. In 1.x, a receiver transaction was created and a separate dispatcher transaction. In 2.x, only a receiver transaction is created and at one point the code for the dispatcher transaction was removed. I wasn't able to find anything meaningful in the svn log on this and hence will provide a patch for review shortly. Maybe someone can explain why we have a separate receiver and dispatcher transaction and how the ultimately cooperate with each other. That sync=true isn't set when using MuleClient.dispatch() is more or less a fallout of the above because the sync variable is controlled by the existence of a transaction instance.

[ Permlink | « Hide ]

Andreas Guenther added a comment - 10/May/08 05:26 PM

Suggested patch to rollback to what's currently implemented in 1.x so that a transaction is available for the dispatcher in its thread.

[ Permlink | « Hide ]

Andreas Guenther added a comment - 14/May/08 11:16 AM

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

[ Permlink | « Hide ]

Andreas Guenther added a comment - 14/May/08 11:44 AM

Follow-up commit: http://fisheye.codehaus.org/changelog/mule/?cs=11756

[ Permlink | « Hide ]

Keith Naas added a comment - 15/May/08 03:59 PM

Something in this change, broke a configuration of ours where the outbound endpoint had a transformer associated to it. The transformer doesn't seem to be called when the message is routed to the endpoint. I have also tried using a restlet endpoint in the inbound side and it does successfully transform the object in the outbound router.

<service>
   <inbound>
                <vm:inbound-endpoint path="vendor.vendorCompliance.inbound.service.restlet"
                    connector-ref="common.internal.synchronous.connector" remoteSync="true" />
            </inbound>

            <outbound>

                <filtering-router>
                    <vm:outbound-endpoint path="vendor.vendorCompliance.internal.service.find"
                        connector-ref="common.internal.synchronous.connector"
                        transformer-refs="vendor.vendorCompliance.inbound.restlet.transformer.restletToVendorComplianceKey" />
                    <message-property-filter pattern="http.method=GET" />
                </filtering-router>
            </outbound>
</service>

[ Permlink | « Hide ]

Andreas Guenther added a comment - 15/May/08 10:19 PM

I am currently investigating this and also opened ~~MULE-3345~~, which most likely is unrelated to what you found. Do transformers generally don't apply in outbound endpoints or just in your particular case above? We have test cases that actually succeed when testing basic transformations on inbound and outbound. Can you provide a more complete example without noise, e.g. filters, that still produces your issue? That'll be helpful for me to reproduce.

-Andreas