Petals ESB Container

Do not remove In, Out or Fault from an Exchange before sending it

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 4.3.0
  • Fix Version/s: 5.0.0
  • Component/s: Router, Transporter
  • Security Level: Public
  • Description:
    Hide

    Before sending an exchange, the router "cleans" its messages to remove those that were already here before, for example if it's a DONE or ERROR status, all message are removed, or if it's an OUT, the IN message is removed.
    There is more strange and not always coherent logic to it.

    We shouldn't do that, I guess the objective is to save bandwidth when transferring over the network, but removing these messages kind of breaks the JBI specs, and makes checking the for state error very difficult (as in PETALSESBCONT-74).

    The alternative is to simply have more "intelligent" transporters (for now only the NIO transporter) so that it only transfers what should be transferred.

    Show
    Before sending an exchange, the router "cleans" its messages to remove those that were already here before, for example if it's a DONE or ERROR status, all message are removed, or if it's an OUT, the IN message is removed. There is more strange and not always coherent logic to it. We shouldn't do that, I guess the objective is to save bandwidth when transferring over the network, but removing these messages kind of breaks the JBI specs, and makes checking the for state error very difficult (as in PETALSESBCONT-74). The alternative is to simply have more "intelligent" transporters (for now only the NIO transporter) so that it only transfers what should be transferred.
  • Environment:
    -

Issue Links

Depends
 

Activity

Descending order - Click to sort in ascending order
Hide
Permalink
Victor NOËL added a comment - Wed, 15 Jul 2015 - 17:49:37 +0200

It's removed for now…

Show
Victor NOËL added a comment - Wed, 15 Jul 2015 - 17:49:37 +0200 It's removed for now…
Hide
Permalink
Victor NOËL added a comment - Wed, 15 Jul 2015 - 17:02:45 +0200

Note: this can't be done for send (async) because it is not the same object used between sending as a consumer and receiving as a consumer: if we remove, for example, the IN message when sending as a provider, then how can the container from the consumer side can know from which object to restore from the IN message?
Or it should store it on the side but then how can it know how long it should keep it?

Or we should do that "optimisation" from within the CDK when using sendAsync and not the container… because sendAsync knows how long the consumer is waiting for its answer!

Show
Victor NOËL added a comment - Wed, 15 Jul 2015 - 17:02:45 +0200 Note: this can't be done for send (async) because it is not the same object used between sending as a consumer and receiving as a consumer: if we remove, for example, the IN message when sending as a provider, then how can the container from the consumer side can know from which object to restore from the IN message? Or it should store it on the side but then how can it know how long it should keep it? Or we should do that "optimisation" from within the CDK when using sendAsync and not the container… because sendAsync knows how long the consumer is waiting for its answer!

People

Dates

  • Created:
    Wed, 15 Jul 2015 - 16:30:35 +0200
    Updated:
    Tue, 21 Jul 2015 - 17:17:38 +0200
    Resolved:
    Tue, 21 Jul 2015 - 17:17:37 +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.