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

Ascending order - Click to sort in descending order
Victor NOËL made changes - Wed, 15 Jul 2015 - 16:31:06 +0200
Field Original Value New Value
Link This issue blocks PETALSESBCONT-74 [ PETALSESBCONT-74 ]
Victor NOËL made changes - Wed, 15 Jul 2015 - 16:43:23 +0200
Assignee Christophe DENEUX [ cdeneux ] Victor NOËL [ vnoel ]
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!
Victor NOËL made changes - Wed, 15 Jul 2015 - 17:49:07 +0200
Status New [ 10000 ] Open [ 10002 ]
Priority Major [ 3 ]
Victor NOËL made changes - Wed, 15 Jul 2015 - 17:49:09 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
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…
Victor NOËL made changes - Tue, 21 Jul 2015 - 17:14:25 +0200
Link This issue blocks PETALSESBCONT-346 [ PETALSESBCONT-346 ]
Victor NOËL made changes - Tue, 21 Jul 2015 - 17:17:38 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Fix Version/s 5.0.0 [ 10413 ]
Resolution Fixed [ 1 ]
Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
1h 18m
1
Victor NOËL
Wed, 15 Jul 2015 - 17:49:07 +0200
Open Open In Progress In Progress
2s
1
Victor NOËL
Wed, 15 Jul 2015 - 17:49:09 +0200
In Progress In Progress Resolved Resolved
5d 23h 28m
1
Victor NOËL
Tue, 21 Jul 2015 - 17:17:38 +0200



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.