[jboss-jira] [JBoss JIRA] (JGRP-1648) FRAG/FRAG2: message batching can lead to incorrect ordering

[Bela Ban (JIRA)]

     [ https://issues.jboss.org/browse/JGRP-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1648:
---------------------------

    Fix Version/s: 3.2.10
                   3.3.3

    
> FRAG/FRAG2: message batching can lead to incorrect ordering
> -----------------------------------------------------------
>
>                 Key: JGRP-1648
>                 URL: https://issues.jboss.org/browse/JGRP-1648
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.2.10, 3.3.3, 3.4
>
>
> The implementation of up(MessageBatch) in FRAG and FRAG2 is incorrect because messages reassmbled from fragments are re-inserted into the batch at the end rather than in the place of the fragments.
> Example: when we receive P1 P2 P3:1 P3:2 P3:3 and P4 (P3 was split into 3 fragments by sender P), then the resulting batch (see the code below) will be P1 P2 P4 P3, as the re-assembled message P3 is added to the *end* of the batch rather than re-inserted in-place.
> {code}
>     public void up(MessageBatch batch) {
>         for(Message msg: batch) {
>             FragHeader hdr=(FragHeader)msg.getHeader(this.id);
>             if(hdr != null) { // needs to be defragmented
>                 batch.remove(msg);
>                 Message assembled_msg=unfragment(msg,hdr);
>                 if(assembled_msg != null)
>                     batch.add(assembled_msg); // the newly added message will not get iterated over by the current iterator !
>             }
>         }
>         if(!batch.isEmpty())
>             up_prot.up(batch);
>     }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira