[ 
https://issues.apache.org/jira/browse/SYNAPSE-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pamod Sylvester updated SYNAPSE-1130:
-------------------------------------
    Description: 
[Resequencer|[https://www.enterpriseintegrationpatterns.com/patterns/messaging/Resequencer.html]
 ] will consolidate out of order messages and ensure that the messages are 
rearranged to the correct order before sending it out.
h1. Description 

Resequencer can have two forms,
h3. Batch Resequencer 
 # Order identifying criteria (based on message body expression etc, 
header)/this should be extensible 
 # Resequencing delimiters (batch size, timeout)

h3. Stream Resequencer
 # Order identifying criteria - header “seqnum”
 # Resequencing delimiters - gap detection/timeout

 

Gap detection - This will ensure that for a given sequence number say 3, the 
predecessor is 2 and the successor is 4. If this doesn’t match it will wait 
until the matching predecessor arrives before sending the message out.
h1. Resequence Message Processor vs Resequence Message Store 

 

At present the resquence processor will introduce the following discrepancies,
 # Messages will be peeked and polled from volatile memory, hence reliability 
guarantees cannot be provided  
 # The algorithm assumes once a message is picked/peeked from store the next 
message could be peeked without having to remove the current message. This 
operation would not resonates with queuing architectures such as JMS (which 
could be introduced in future; for message stores).  
 # Implementation is based on stream sequencing. Batch sequencing is not 
supported 

 

Hence it's important to note; for EIPs such as resequencer a more non volatile 
store is required. Further options such as batch resequencing is required.  

  

  was:
[Resequencer|[https://www.enterpriseintegrationpatterns.com/patterns/messaging/Resequencer.html]
 ] will consolidate out of order messages and ensure that the messages are 
rearranged to the correct order before sending it out.
h1. Description 

Resequencer can have two forms,
h3. Batch Resequencer 
 # Order identifying criteria (based on message body expression etc, 
header)/this should be extensible 
 # Resequencing delimiters (batch size, timeout)

h3. Stream Resequencer
 # Order identifying criteria - header “seqnum”
 # Resequencing delimiters - gap detection/timeout

 

Gap detection - This will ensure that for a given sequence number say 3, the 
predecessor is 2 and the successor is 4. If this doesn’t match it will wait 
until the matching predecessor arrives before sending the message out.
h1. Resequence Message Processor vs Resequence Message Store 

 

At present the resquence processor will introduce the following discrepancies,
 # Messages will be peeked and polled from volatile memory, hence reliability 
guarantees cannot be provided  
 # The algorithm assumes once a message is picked/peeked from store the next 
message could be peeked without having to remove the current message. This 
operation would not resonate with queuing architectures such as JMS (which 
could be introduced in future; for message stores).  
 # Implementation is based on stream sequencing. Batch sequencing is not 
supported 

 

Hence it's important to note; for EIPs such as resequencer a more non volatile 
store is required. Further options such as batch resequencing is required.  

  


> Introduce Resequence Message Store
> ----------------------------------
>
>                 Key: SYNAPSE-1130
>                 URL: https://issues.apache.org/jira/browse/SYNAPSE-1130
>             Project: Synapse
>          Issue Type: Sub-task
>          Components: Core
>    Affects Versions: 3.0.1
>            Reporter: Pamod Sylvester
>            Assignee: Isuru Udana
>            Priority: Major
>              Labels: features
>             Fix For: FUTURE
>
>
> [Resequencer|[https://www.enterpriseintegrationpatterns.com/patterns/messaging/Resequencer.html]
>  ] will consolidate out of order messages and ensure that the messages are 
> rearranged to the correct order before sending it out.
> h1. Description 
> Resequencer can have two forms,
> h3. Batch Resequencer 
>  # Order identifying criteria (based on message body expression etc, 
> header)/this should be extensible 
>  # Resequencing delimiters (batch size, timeout)
> h3. Stream Resequencer
>  # Order identifying criteria - header “seqnum”
>  # Resequencing delimiters - gap detection/timeout
>  
> Gap detection - This will ensure that for a given sequence number say 3, the 
> predecessor is 2 and the successor is 4. If this doesn’t match it will wait 
> until the matching predecessor arrives before sending the message out.
> h1. Resequence Message Processor vs Resequence Message Store 
>  
> At present the resquence processor will introduce the following discrepancies,
>  # Messages will be peeked and polled from volatile memory, hence reliability 
> guarantees cannot be provided  
>  # The algorithm assumes once a message is picked/peeked from store the next 
> message could be peeked without having to remove the current message. This 
> operation would not resonates with queuing architectures such as JMS (which 
> could be introduced in future; for message stores).  
>  # Implementation is based on stream sequencing. Batch sequencing is not 
> supported 
>  
> Hence it's important to note; for EIPs such as resequencer a more non 
> volatile store is required. Further options such as batch resequencing is 
> required.  
>   



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org

Reply via email to