Petals ESB Container

Verification of state when changing status is buggy in MessageExchangeImpl

Details

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

    In the container MessageExchange implementation, there seems to be error in the logic that checks the state of an exchange when the status is set (in method setStatus()).

    For example, it is not possible to set the Error status when one is provider and the message is in-out... there is no reason for this specific case.
    There is also some strange case where the provider can't set the done status on an InOnly message with a fault... which cannot happen at that point normally!

    This should be fixed.

    Show
    In the container MessageExchange implementation, there seems to be error in the logic that checks the state of an exchange when the status is set (in method setStatus()). For example, it is not possible to set the Error status when one is provider and the message is in-out... there is no reason for this specific case. There is also some strange case where the provider can't set the done status on an InOnly message with a fault... which cannot happen at that point normally! This should be fixed.
  • Environment:
    -

Issue Links

Depends
 

Activity

Descending order - Click to sort in ascending order



Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
12s
1
Victor NOËL
Mon, 11 May 2015 - 16:07:31 +0200
Open Open In Progress In Progress
9d 22h 55m
1
Victor NOËL
Thu, 21 May 2015 - 15:03:09 +0200
In Progress In Progress Resolved Resolved
2h 4m
1
Victor NOËL
Thu, 21 May 2015 - 17:07:53 +0200
Hide
Permalink
Victor NOËL added a comment - Fri, 29 Jan 2016 - 16:56:49 +0100

Backported to Petals 4.3 in svn#39008

Show
Victor NOËL added a comment - Fri, 29 Jan 2016 - 16:56:49 +0100 Backported to Petals 4.3 in svn#39008
Victor NOËL made changes - Fri, 29 Jan 2016 - 16:56:15 +0100
Fix Version/s 4.3.2 [ 10608 ]
Victor NOËL made changes - Thu, 21 May 2015 - 17:07:53 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Fix Version/s 5.0.0 [ 10413 ]
Resolution Fixed [ 1 ]
Hide
Permalink
Victor NOËL added a comment - Thu, 21 May 2015 - 17:07:53 +0200

It is fixed.

Errors can be set at anytime (except if the exchange is already finished).

Show
Victor NOËL added a comment - Thu, 21 May 2015 - 17:07:53 +0200 It is fixed. Errors can be set at anytime (except if the exchange is already finished).
Victor NOËL made changes - Thu, 21 May 2015 - 15:03:09 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Hide
Permalink
Victor NOËL added a comment - Tue, 12 May 2015 - 10:32:22 +0200

I'm a bit bothered about that "ERROR status" thing: the specs does not say that you can't set ERROR at any time, and even the setError method does not throw the usual MessagingException that is used to indicate there is a state problem.

I would thus say that we can set an error at anytime!

Show
Victor NOËL added a comment - Tue, 12 May 2015 - 10:32:22 +0200 I'm a bit bothered about that "ERROR status" thing: the specs does not say that you can't set ERROR at any time, and even the setError method does not throw the usual MessagingException that is used to indicate there is a state problem. I would thus say that we can set an error at anytime!
Hide
Permalink
Victor NOËL added a comment - Mon, 11 May 2015 - 17:36:58 +0200

And there is also a potential problem for checking state:
the cleanMessage of MessageExchangeImpl is called by the Router to remove unused message, so we can't rely on existing messages to know what is allowed apparently… For example we can't check if there is both an out and a fault in an InOptionalOut to allow a provider to set done (because if there is only a fault, then it may be because it just set the fault, while if there is both, it means it received the fault!).

Well…

Show
Victor NOËL added a comment - Mon, 11 May 2015 - 17:36:58 +0200 And there is also a potential problem for checking state: the cleanMessage of MessageExchangeImpl is called by the Router to remove unused message, so we can't rely on existing messages to know what is allowed apparently… For example we can't check if there is both an out and a fault in an InOptionalOut to allow a provider to set done (because if there is only a fault, then it may be because it just set the fault, while if there is both, it means it received the fault!). Well…
Hide
Permalink
Victor NOËL added a comment - Mon, 11 May 2015 - 17:25:09 +0200

And do we agree that nobody should call setStatus with the state ACTIVE? Or is there reasons for that?

Show
Victor NOËL added a comment - Mon, 11 May 2015 - 17:25:09 +0200 And do we agree that nobody should call setStatus with the state ACTIVE? Or is there reasons for that?
Hide
Permalink
Victor NOËL added a comment - Mon, 11 May 2015 - 16:39:33 +0200

So one can't set an error if it could play is role in the pattern (such as setting an out or a fault), right?

Ok

Show
Victor NOËL added a comment - Mon, 11 May 2015 - 16:39:33 +0200 So one can't set an error if it could play is role in the pattern (such as setting an out or a fault), right? Ok
Hide
Permalink
Christophe DENEUX added a comment - Mon, 11 May 2015 - 16:36:49 +0200

I think that we can process status "Error" as the status "Done" for checks against message OUT and fault.

Show
Christophe DENEUX added a comment - Mon, 11 May 2015 - 16:36:49 +0200 I think that we can process status "Error" as the status "Done" for checks against message OUT and fault.
Hide
Permalink
Victor NOËL added a comment - Mon, 11 May 2015 - 16:30:54 +0200

Christophe, about 2, yes, I made a mistake in the description, I corrected it. About 1, the test didn't check if there was an OUT message…

Also, there can be an error happening after the out was set maybe… the spec says nothing about errors and their relation to patterns, remember?

Show
Victor NOËL added a comment - Mon, 11 May 2015 - 16:30:54 +0200 Christophe, about 2, yes, I made a mistake in the description, I corrected it. About 1, the test didn't check if there was an OUT message… Also, there can be an error happening after the out was set maybe… the spec says nothing about errors and their relation to patterns, remember?
Victor NOËL made changes - Mon, 11 May 2015 - 16:29:03 +0200
Link This issue depends on PETALSCDK-130 [ PETALSCDK-130 ]
Hide
Permalink
Victor NOËL added a comment - Mon, 11 May 2015 - 16:27:57 +0200

And of course, to fix it, we first need to NOT create fault everytime there is an error, because it is forbidden and until now we didn't see it because setting the error state on an exchange didn't change the status...

Show
Victor NOËL added a comment - Mon, 11 May 2015 - 16:27:57 +0200 And of course, to fix it, we first need to NOT create fault everytime there is an error, because it is forbidden and until now we didn't see it because setting the error state on an exchange didn't change the status...
Hide
Permalink
Christophe DENEUX added a comment - Mon, 11 May 2015 - 16:23:54 +0200
  1. If an OUT message is set into the exchange, a provider can't returned a status error until it removes the OUT message. Such a check is done to respect MEP. We can't have an OUT reply and a status concurrently
  2. According to JBI specs, into an In-Out message exchange pattern, the provider CAN'T send a status Done. Only the consumer can do this !
Show
Christophe DENEUX added a comment - Mon, 11 May 2015 - 16:23:54 +0200
  1. If an OUT message is set into the exchange, a provider can't returned a status error until it removes the OUT message. Such a check is done to respect MEP. We can't have an OUT reply and a status concurrently
  2. According to JBI specs, into an In-Out message exchange pattern, the provider CAN'T send a status Done. Only the consumer can do this !
Victor NOËL made changes - Mon, 11 May 2015 - 16:17:43 +0200
Description In the container MessageExchange implementation, there seems to be error in the logic that checks the state of an exchange when the status is set (in method setStatus()).

For example, it is not possible to set the Error status when one is provider and the message is in-out... there is no reason for this specific case.
Also, a provider can't set DONE on an in-out message, there is no reason for that, actually the opposite would be expected when a provider has set the out message or even the fault message!

This should be fixed. 		In the container MessageExchange implementation, there seems to be error in the logic that checks the state of an exchange when the status is set (in method setStatus()).

For example, it is not possible to set the Error status when one is provider and the message is in-out... there is no reason for this specific case.
There is also some strange case where the provider can't set the done status on an InOnly message with a fault... which cannot happen at that point normally!

This should be fixed.
Victor NOËL made changes - Mon, 11 May 2015 - 16:07:31 +0200
Field Original Value New Value
Status New [ 10000 ] Open [ 10002 ]
Priority Blocker [ 1 ]
Assignee Christophe DENEUX [ cdeneux ] Victor NOËL [ vnoel ]

People

Dates

  • Created:
    Mon, 11 May 2015 - 16:07:19 +0200
    Updated:
    Fri, 29 Jan 2016 - 16:56:49 +0100
    Resolved:
    Thu, 21 May 2015 - 17:07:53 +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.