Transformer set on Endpoint before type known

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 2.0.0-M1
  • Fix Version/s: 2.0.0-M1
  • Component/s: Core: Configuration
  • Labels:
    None
  • User impact:
    High
  • Similar Issues:
    None

Description

The ImmutableMuleEndpoint class has the following code:

if (transformer == null)
        {
            if (connector instanceof AbstractConnector)
            {
                if (UMOEndpoint.ENDPOINT_TYPE_SENDER.equals(type))
                {
                    transformer = ((AbstractConnector) connector).getDefaultOutboundTransformer();
                }
                else if (UMOEndpoint.ENDPOINT_TYPE_SENDER_AND_RECEIVER.equals(type))
                {
                    transformer = ((AbstractConnector) connector).getDefaultInboundTransformer();
                }
                else
                {
                    transformer = ((AbstractConnector) connector).getDefaultInboundTransformer();
                }
            }
        }

When this is called, type is "senderAndReceiver". Always. The value of type is only changed later, when setType is called by the router collection.

I believe this was responsible for some of the problems in MULE-1840 ("I cannot make everything identical to the pre-2.0 behaviour; I believe that it's just not possible given the changes to startup.")

It is also related to MULE-1956 and MULE-1922.

Issue Links

is duplicated by

Improvement - An improvement or enhancement to an existing feature or task. MULE-1922 Improve Initialisation in 2.0

  • 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

Bug - A problem which impairs or prevents the functions of the product. MULE-1999 Outbound endpoints use the default inbound transformer

  • Major - Major loss of function.
  • 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-2058 Incorrect transformer is used when processing replyTo's

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andrew Cooke added a comment -

Added lazy init. Better fix postponed to MULE-1956.

Show
Andrew Cooke added a comment - Added lazy init. Better fix postponed to MULE-1956.
Hide
Permalink
Andrew Cooke added a comment -

setTransformer in mutable subclass breaks assumptions in lazy init. see andrew p's email to dev.

Show
Andrew Cooke added a comment - setTransformer in mutable subclass breaks assumptions in lazy init. see andrew p's email to dev.
Hide
Permalink
Andrew Cooke added a comment -

It's hard to fix this because the original semantics were too loosely defined. For example: it seems as though null is a valid value for the transformer in some situations, but it is also used to indicate the uninitialised state; there is the possibility for the transformer to be updated via subclasses, but much code assumes the transformer value does not change (eg successive logical operations).

I've made what I hope is a reasonable compromise - I've separated null from "uninitialised", made updates atomic, and used separate "instantaneous values" when the transformer is used internally. Initialisation uses compare and swap, is only effective if the current value is "uninitialised", occurs just once (after which "uninitialised" becomes "null") and generation of the "replace" value is short-circuited if initialisation has already occurred.

Show
Andrew Cooke added a comment - It's hard to fix this because the original semantics were too loosely defined. For example: it seems as though null is a valid value for the transformer in some situations, but it is also used to indicate the uninitialised state; there is the possibility for the transformer to be updated via subclasses, but much code assumes the transformer value does not change (eg successive logical operations). I've made what I hope is a reasonable compromise - I've separated null from "uninitialised", made updates atomic, and used separate "instantaneous values" when the transformer is used internally. Initialisation uses compare and swap, is only effective if the current value is "uninitialised", occurs just once (after which "uninitialised" becomes "null") and generation of the "replace" value is short-circuited if initialisation has already occurred.
Hide
Permalink
Andrew Cooke added a comment -

See comment on dev re readResolve (not yet looked at code myself; waiting for build in IDE).

Show
Andrew Cooke added a comment - See comment on dev re readResolve (not yet looked at code myself; waiting for build in IDE).
Hide
Permalink
Andrew Cooke added a comment -

Closing this again for now.

Andrew P raised some issues about the singleton implementation - see discussion on dev. I addressed some, but others seem to be either related to serialization or (if I understand classloader issues correctly) imply that the problem is much wider than just this code (no singleton equality appears to be correct), in which case we probably want a different issue.

Show
Andrew Cooke added a comment - Closing this again for now. Andrew P raised some issues about the singleton implementation - see discussion on dev. I addressed some, but others seem to be either related to serialization or (if I understand classloader issues correctly) imply that the problem is much wider than just this code (no singleton equality appears to be correct), in which case we probably want a different issue.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: