Petals ESB Container

Implementation of MessageExchange does not respect owner contract

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 4.2.4
  • Fix Version/s: 5.0.0
  • Component/s: Micro-kernel
  • Security Level: Public
  • Description:
    Hide

    Operations on MessageExchange should throw IllegalStateException when a component that does not own the exchange in the current state calls them.

    The bug is caused by the fact that MessageExchangeWrapper, which is responsible of doing that check, is shared between consumer and provider and thus doesn't reflect correctly the role of the owner of a reference to the message as it should.
    (The code was actually documented as doing that, even though it wasn't, until commit r37114 where I corrected the documentation without realising the code should be fixed instead .

    A solution is to actually have 2 instances of the MessageExchangeWrapper, one for each actor of the exchange, so that their observerRole field actually reflect the reality.

    The problem is that many code in the kernel relies on the fact that the object is shared between the consumer and the provider.

    Show
    Operations on MessageExchange should throw IllegalStateException when a component that does not own the exchange in the current state calls them. The bug is caused by the fact that MessageExchangeWrapper, which is responsible of doing that check, is shared between consumer and provider and thus doesn't reflect correctly the role of the owner of a reference to the message as it should. (The code was actually documented as doing that, even though it wasn't, until commit r37114 where I corrected the documentation without realising the code should be fixed instead . A solution is to actually have 2 instances of the MessageExchangeWrapper, one for each actor of the exchange, so that their observerRole field actually reflect the reality. The problem is that many code in the kernel relies on the fact that the object is shared between the consumer and the provider.
  • Environment:
    -

Issue Links

Depends
 

Activity

Descending order - Click to sort in ascending order
Hide
Permalink
Victor NOËL added a comment - Wed, 29 Jul 2015 - 10:54:32 +0200

FYI, the petals-mail-storage helper component for the mail integration tests was storing Exchange, and after sending them back, it lost ownership: later on, when accessing them to get their in content, exceptions were thrown… it was easy to fix, but we should be careful about that kind of things!

Show
Victor NOËL added a comment - Wed, 29 Jul 2015 - 10:54:32 +0200 FYI, the petals-mail-storage helper component for the mail integration tests was storing Exchange, and after sending them back, it lost ownership: later on, when accessing them to get their in content, exceptions were thrown… it was easy to fix, but we should be careful about that kind of things!
Hide
Permalink
Victor NOËL added a comment - Mon, 27 Jul 2015 - 16:05:56 +0200

Resolved, now we just need to fix PETALSCDK-140.

Show
Victor NOËL added a comment - Mon, 27 Jul 2015 - 16:05:56 +0200 Resolved, now we just need to fix PETALSCDK-140.
Hide
Permalink
Victor NOËL added a comment - Mon, 27 Jul 2015 - 16:02:37 +0200

In a way, a solution to this problem could take PETALSCDK-14 into account.

Show
Victor NOËL added a comment - Mon, 27 Jul 2015 - 16:02:37 +0200 In a way, a solution to this problem could take PETALSCDK-14 into account.
Hide
Permalink
Victor NOËL added a comment - Mon, 27 Jul 2015 - 16:01:04 +0200

Apparently, the problem is that once DeliveryChannel.send has been called, we can't access anymore anything from the exchange.

Show
Victor NOËL added a comment - Mon, 27 Jul 2015 - 16:01:04 +0200 Apparently, the problem is that once DeliveryChannel.send has been called, we can't access anymore anything from the exchange.
Hide
Permalink
Victor NOËL added a comment - Mon, 27 Jul 2015 - 15:58:52 +0200

This is almost fixed, but there is still problems with the CDK

Show
Victor NOËL added a comment - Mon, 27 Jul 2015 - 15:58:52 +0200 This is almost fixed, but there is still problems with the CDK
Hide
Permalink
Victor NOËL added a comment - Wed, 22 Jul 2015 - 16:57:26 +0200

Some citation from the specification to clarify the meaning of ownership (p. 45):

MessageExchange instances are owned by either the initiator, servicer, or NMR. Creating or accepting a message exchange instance confers ownership on the creating (or accepting) component. Upon calling send() for a particular ME instance, the component surrenders ownership of the ME instance immediately. sendSync() causes ownership to be surrendered during the course of the call; when the call ends (returning true) the component resumes ownership of the ME instance. Ownership of an ME instance gives the owner the right to read from and write to the instance. When a component (or the NMR) doesn't have ownership of an ME instance, it MUST NOT read from or write to the instance, except for reading the message exchange status, which can be queried regardless of ownership. If a component that is not the current owner of the instance does attempt to call any method (other than getStatus()) on the instance an appropriate java.lang.IllegalStateException MUST be thrown.

Show
Victor NOËL added a comment - Wed, 22 Jul 2015 - 16:57:26 +0200 Some citation from the specification to clarify the meaning of ownership (p. 45):
MessageExchange instances are owned by either the initiator, servicer, or NMR. Creating or accepting a message exchange instance confers ownership on the creating (or accepting) component. Upon calling send() for a particular ME instance, the component surrenders ownership of the ME instance immediately. sendSync() causes ownership to be surrendered during the course of the call; when the call ends (returning true) the component resumes ownership of the ME instance. Ownership of an ME instance gives the owner the right to read from and write to the instance. When a component (or the NMR) doesn't have ownership of an ME instance, it MUST NOT read from or write to the instance, except for reading the message exchange status, which can be queried regardless of ownership. If a component that is not the current owner of the instance does attempt to call any method (other than getStatus()) on the instance an appropriate java.lang.IllegalStateException MUST be thrown.

People

Dates

  • Created:
    Thu, 23 Apr 2015 - 10:45:44 +0200
    Updated:
    Wed, 29 Jul 2015 - 10:54:33 +0200
    Resolved:
    Mon, 27 Jul 2015 - 16:05:56 +0200
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Petals ESB. Try JIRA - bug tracking software for your team.