Jump to: navigation, search

Difference between revisions of "SMILA/Specifications/ProcessingMessageResequencer"

(The Core Problem)
(Solution Proposals)
 
(26 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
[[Category:SMILA]]
 
[[Category:SMILA]]
 +
 +
{{Note|Status| this page is very much a WIP and discussion is still happening on the [http://dev.eclipse.org/mhonarc/lists/smila-dev/msg00608.html dev list].
 +
* 2009 10 02 major changes to reflect newest insights
 +
 +
as the concept matures during the discussion this page will be updated in certain intervals.
 +
 +
this enhancement is tracked thru {{Bug|289995}}
 +
 +
for the development i opened a new branch @ https://dev.eclipse.org/svnroot/rt/org.eclipse.smila/branches/2009-09-23_r608_resequencer}}
  
 
=== The Core Problem  ===
 
=== The Core Problem  ===
  
MQs are inherently asynchronous but in the end we need to be sure that the final processing target reflects the correct state of the data source at any given time.  
+
When listening with >1 listener on a Q or with selectors there is no guarantee that the order of processing requests (PR) is maintained as intended. However, at the end of processing we need to be sure that the final processing target reflects the correct state of the data source at any given time.  
  
The needs of the final processing target might differ in their requirements. At this time we will only treat the case of an full text retrieval engine like lucene.  
+
The needs of the final processing target might differ in their requirements. At this time we will only treat the case of a full text retrieval engines, like Lucene.
  
this enhancement is tracked tru https://bugs.eclipse.org/bugs/show_bug.cgi?id=289995
+
SMILA/Specifications/ProcessingMessageResequencer
 +
=== Indexing Requirements ===
  
=== Indexing  Requirements ===
+
the requirements for indexing are a little relaxed compared to the general case. These are the simplifications:
 +
* the order needs only to be maintained on a per record base
 +
* older PRs are always superseded by newer PR for a given resource. the outcome of these operations can be discarded -- or even better: processing of these could be suppressed.
  
 +
The following requirements are just a complete list of possible demands an application may impose. There is no implicit statement attached to the likelihood that a particular requirement is requested by an application, although there might be such. The intent of the list is to have a complete enumeration. qualification for an item is merely: may such a case, however unlikely, exist?
  
- the order needs only to be maintained on a per record base
+
The solutions are to outline how a specific requirement may be implemented or covered. It also may chose to not cover it. An application may then chose a solution that matches its needs. As usual the requirements are split into functional and non-functional.
-  older messages are superseded by newer messages for a resource and can be removed from the MQ w/o further processing
+
 
 +
==== Functional ====
 +
 
 +
===== Basic Operations =====
  
 
{{CTable}}
 
{{CTable}}
Line 25: Line 41:
 
|}
 
|}
  
 +
the following sections names the cases/scenarios  that need to be covered that dont come to mind mediately but need to be considered nonetheless:
  
=== Idea 1 - Handle Resequenceing in Connectivity  ===
+
===== compound management, splitting of records =====
  
There was an original idea to handle this case in the connectivity directly with the help of a buffer.
+
two cases of compounds need to be distinguished here: aggregations and compositions.
  
I dont persue this idea any further because we would need some configuration to tell connectivity where to remove messages and provide necessary API in the modules down the processing chain which seems very messy to me.
+
as in UML, aggregation means that the parent has a dependency to the child but the child may exist  (as a child or even distinctly on its own) elsewhere. composition in contrast '''owns''' the descendants, meaning that they cant be accessed or created independent of the parent. life cycle of the child is controlled by the parent.
 +
the two cases will be discussed in the context of processing now:
  
 +
====== Composition ======
 +
this is the easier case for resquencing b/c only the one processing step working on the root item is possible to create PRs for child item. the ID of a child item will always include the parent id in some sort of way. thus resequencing the parent and its children as a whole is sufficient. (an internal ordering of parent and descendants may be required and is discussed below.)
  
=== Idea 2 - Full Resequencer ===
+
====== Aggregation ======
  
Synopis: The Resequencer will update the lucene index in the exact order as the crawler or agent adds records to the queue.
+
the referenced item may be referenced
 +
* by some other item OR
 +
* may exist on its own.  
  
The processing will be like so:
+
as a consequence
#  the router will feed Q1 with ADD and DELETE ops. For the resequencer to know the order a new meta info needs to be added -- the sequence number. it must be generated in the agent or by the agentcontroler
+
* several diff. root items may hold a reference to it OR
the processing piplines are as normal but
+
* the child item is being processed as a root itself.
## w/o the step of calling the lucene service
+
## they add the result to a new queue, Q2
+
#  the Resequencer will listen on Q2 and picks up all messages
+
#  starting with the first record, feed consecutive chunks of IDs to the lucene service 
+
#  when messages get lost in the DLQ then a timeout can solve this problem
+
  
 +
an application may require to handle these cases in these ways:
 +
# referenced items are to be seen only in context to the parent or on their own. <br>e.g. it does not make it apparent that the child belong to A is in fact the same as belonging to B OR the same root item C . <br>this leads to an identical handling as with compositions and in each case a records is added to the index.
 +
# referenced items are to be seen as distinct items, making the relationships apparent<br> in this case the ID is generated always in the same way independently of the parent.  Only one record for the child is added to the index. the child record will either contain no reference to the parent(s) or lists all of them.
 +
# the third way of handling this, is to do both.
  
==== PRO ====
+
if the application requires
* no processing target can ask for more and correct result is always possible
+
* to handle references as distinct or shared items (2nd and 3rd case) AND
* it is possible to add a note into the index for records ending up in the DLQ, ie. record was not indexed due to processing error.
+
* child items must be processed at the time of the parent (can happen if no change event is ever fired for the child or accessible),
 +
... then aggregation poses the more challenging case in regard to resequencing. B/c new items are created during processing by possibly diff. items the parent item cannot be used as means of ordering the child items. Even less so, if the item may also be added on its own w/o a parent. instead there must be some means that created (split) records are ordered in their own realm.
  
==== CON ====
+
====== Parent/Descendants Ordering  Requirement ======
* overkill, b/c there is no need to resequence all messages, only those with same ID
+
  
 +
this requirement applies to the case
 +
* where the child is handled in the context of the parent (composition and 1st case aggregation) AND
 +
* the order of processing of descendants matters.
  
 +
depending on the application's need  the descends (ie. all records created from one record ) must be processed in a certain order.
  
=== Idea 3 - Smart Resequencer  ===
+
parent/child associatens ususally result in a tree structure. there are 4 basic ways to traverse a tree, namely:
 +
* root to leaf, breadth first
 +
* root to leaf, depth first
 +
* leaf to root, breadth first
 +
* leaf to root, depth first
  
Synopis: The Resequencer will  process only the most recent operation per resource added by the agent, suppressing the older ones
+
appart from this, applications may have special processing needs and as such an own, custom implementation must be supported.
  
The processing will be similar to the Full Resequencer and is then like so:
+
===== support >1 processing targets =====
#  the router will feed Q1 with ADD and DELETE ops. For the resequencer to know the order a new meta info needs to be added -- the sequence number. it must be generated in the agent or by the agentcontroler
+
the same record is processed and added to more than one processing target (PT), such as an 2 diff. search indexs, having diff. structures for diff. tasks.
# the Resequencer will  
+
* it is possible and likely that the records for the same resource will look differently.
## subscripe to/peek into Q1 w/o taking messages from the Q. It remembers in a Map the id and seq#.
+
* diff. pipleines and branches may be executed to get to the PT
## when the map contained already an entry for the ID then it may remove messages for this ID from Qs stoping them from being processed further. this needs howevrt the hash tp be present as a JMX property.
+
* some PRs of the same data source may only be added to one PT while other are added to several and others are chose not to be processed at all.  
# the processing piplines are as normal but
+
## w/o the step of calling the lucene service
+
## they add the result to a new queue, Q2
+
#  the Resequencer will listen on Q2 and pick up all messages. for each  message:
+
##  IF its seq# matches the one in the map THEN <br/> call the index service for the record <br/> ELSE <br/> ignore and skip operation <br>FI
+
## remove ID from map
+
  
==== PRO ====
+
===== complex processing chains =====
- smarter ;)
+
 
 +
the processing chain (or workflow) may be arbitrarily complex with forks and joins, consisting of several pipelines which may contain any number of pipelets. the path a PR travels is controlled by the rules of pipeline listeners and conditions on their pipelets.<br>in the cases of some setups and due to the nature of concurrency, the same PR may undergo complete different processing steps and it is not foreseeable which route it takes (though such a case is likely a misconfiguration).
 +
 
 +
===== parallel processing branches =====
 +
 
 +
in particular, a workflow may also contain parallel processing branches where the same PR is sent several times ( i.e. creating copies of the same PR ) to  diff. Qs and/or with diff. JMS properties for consumption by diff. workflows. <br> a use case for such a scenario is when the items shall be indexed or stored by completely diff. PTs and where the pre-processing steps are different in the two branches.
 +
 
 +
in this case, it is inherent in the parallel workflow design, that several PRs for the same item exists in the workflow for some period of time. this results automatically in write conflicts and bugs when using a shared record, as is now the case with a persisting BB. therefore in such a case only a transient BB is allowed!
 +
 
 +
workarounds lifting this limitation are:
 +
* have a persisting BB per processing branch. an OOB working setup for this is to execute the parallel processing branches on different nodes in a cluster setup or run several SMILA instances on the same box.
 +
* modify the ID such that it becomes unique for each parallel processing branch
 +
* implementing the partition concept for the storages, where each parallel branch will have its own partition.
 +
 
 +
===== clustering =====
 +
this means the setup where processing is spread to diff. nodes in a cluster. it also includes usage of several MQs and/or piplines.
 +
 
 +
'''Assumption:''' there is just one instance on just one node to handle all access to the processing target.
 +
 
 +
===== oscillating items  =====
 +
these are items that constantly change and where the update intervall usually is smaller then it takes to process them.
 +
 
 +
==== Non - Functional ====
 +
 
 +
===== single point of failure =====
 +
the solution (ideally) doesnt pose an SPOF.
 +
 
 +
===== scalability and performance =====
 +
this is a general requirement and the solution shall outline under this section the impact on performance and where possible bottlenecks are.
 +
 
 +
=== Solution Proposals ===
 +
 
 +
* [[SMILA/Specifications/Processing_Message_Resequencer/Connectivity_Consolidation_Buffer| Connectivity Consolidation Buffer (CBC)]]
 +
* [[SMILA/Specifications/Processing_Message_Resequencer/Full_Resequencer | Full Resequencer (FRS)]]
 +
* [[SMILA/Specifications/Processing_Message_Resequencer/Smart_Resequencer | Smart Resequencer (SRS)]]
 +
* [[SMILA/Specifications/Processing_Message_Resequencer/Skip_Pipelet|Skip Pipelet (SP)]]
 +
* [[SMILA/Specifications/Processing_Message_Resequencer/Record_Version_Number|Record Version Number (RVN)]]
 +
 
 +
=== General Problems ===
 +
 
 +
 
 +
==== Shared Record Instance via Blackboard ====
 +
 
 +
sharing the records via the BB for all processing steps introduces a grave concurrency bug. this is outlined in my mail @ [[http://dev.eclipse.org/mhonarc/lists/smila-dev/msg00618.html RE: Message Resequencer :: concept bug detected and general SMILA concurrency problem]]
 +
 
 +
for the time being using a transient BB should solve the problem but is really not the ideal solution. in the end we need partitions for the BB that solve this issue IMO.
 +
 
 +
=== Appendix ===
 +
 
 +
==== Abreviations ====
 +
 
 +
{{CTable}}
 +
| Abrev || Meaning
 +
|-
 +
| SN || Sequence Number
 +
|-
 +
| RS || Resquecer Service
 +
|-
 +
| FRS|| Full Resequencer Service
 +
|-
 +
| SRS|| Smart Resequencer Service
 +
|-
 +
| Q  || the Queue as used in a Message Queue
 +
|-
 +
| PR  || processing request, ie to either add or delete a resource and do the needed processing for that. the PR is the combination of JMS message and record.
 +
'''NOTE:'''  it is legal to have >1 PRs for the same recource on the processing chain. this concept's goal is to bring the PRs into proper order and not neccessarily have just one PR per resource in the processing chain.<br>
 +
'''NOTE:''' the term "message" is often used interchangably for this, albeit not quite correct.
 +
|-
 +
|  PT  || processing target, basically any pipelet that stores some information on the record other than in Bin- or records storage and where the processing order matters. A search index is an example of this.
 +
|-
 +
|  CA  || Config Annotation. A specially named annotation that is attached to the record holding all needed information the RS needs to do its work.
 +
|}
  
==== CON ====
+
==== Ideas ====
- ossilating resources (that constantly change) will never make it into the index
+
* replace the SN with a more general ComparableObject

Latest revision as of 07:09, 9 October 2009


Note.png
Status
this page is very much a WIP and discussion is still happening on the dev list.
  • 2009 10 02 major changes to reflect newest insights

as the concept matures during the discussion this page will be updated in certain intervals.

this enhancement is tracked thru bug 289995

for the development i opened a new branch @ https://dev.eclipse.org/svnroot/rt/org.eclipse.smila/branches/2009-09-23_r608_resequencer


The Core Problem

When listening with >1 listener on a Q or with selectors there is no guarantee that the order of processing requests (PR) is maintained as intended. However, at the end of processing we need to be sure that the final processing target reflects the correct state of the data source at any given time.

The needs of the final processing target might differ in their requirements. At this time we will only treat the case of a full text retrieval engines, like Lucene.

SMILA/Specifications/ProcessingMessageResequencer

Indexing Requirements

the requirements for indexing are a little relaxed compared to the general case. These are the simplifications:

  • the order needs only to be maintained on a per record base
  • older PRs are always superseded by newer PR for a given resource. the outcome of these operations can be discarded -- or even better: processing of these could be suppressed.

The following requirements are just a complete list of possible demands an application may impose. There is no implicit statement attached to the likelihood that a particular requirement is requested by an application, although there might be such. The intent of the list is to have a complete enumeration. qualification for an item is merely: may such a case, however unlikely, exist?

The solutions are to outline how a specific requirement may be implemented or covered. It also may chose to not cover it. An application may then chose a solution that matches its needs. As usual the requirements are split into functional and non-functional.

Functional

Basic Operations
Operation N Operation N+1 expected index State after N+1
ADD A,t1 ADD A,t2 A,t2
ADD A,t1 DELETE A,t2 A doesn't exist
DELETE A,t1 ADD A,t2 A exists

the following sections names the cases/scenarios that need to be covered that dont come to mind mediately but need to be considered nonetheless:

compound management, splitting of records

two cases of compounds need to be distinguished here: aggregations and compositions.

as in UML, aggregation means that the parent has a dependency to the child but the child may exist (as a child or even distinctly on its own) elsewhere. composition in contrast owns the descendants, meaning that they cant be accessed or created independent of the parent. life cycle of the child is controlled by the parent. the two cases will be discussed in the context of processing now:

Composition

this is the easier case for resquencing b/c only the one processing step working on the root item is possible to create PRs for child item. the ID of a child item will always include the parent id in some sort of way. thus resequencing the parent and its children as a whole is sufficient. (an internal ordering of parent and descendants may be required and is discussed below.)

Aggregation

the referenced item may be referenced

  • by some other item OR
  • may exist on its own.

as a consequence

  • several diff. root items may hold a reference to it OR
  • the child item is being processed as a root itself.

an application may require to handle these cases in these ways:

  1. referenced items are to be seen only in context to the parent or on their own.
    e.g. it does not make it apparent that the child belong to A is in fact the same as belonging to B OR the same root item C .
    this leads to an identical handling as with compositions and in each case a records is added to the index.
  2. referenced items are to be seen as distinct items, making the relationships apparent
    in this case the ID is generated always in the same way independently of the parent. Only one record for the child is added to the index. the child record will either contain no reference to the parent(s) or lists all of them.
  3. the third way of handling this, is to do both.

if the application requires

  • to handle references as distinct or shared items (2nd and 3rd case) AND
  • child items must be processed at the time of the parent (can happen if no change event is ever fired for the child or accessible),

... then aggregation poses the more challenging case in regard to resequencing. B/c new items are created during processing by possibly diff. items the parent item cannot be used as means of ordering the child items. Even less so, if the item may also be added on its own w/o a parent. instead there must be some means that created (split) records are ordered in their own realm.

Parent/Descendants Ordering Requirement

this requirement applies to the case

  • where the child is handled in the context of the parent (composition and 1st case aggregation) AND
  • the order of processing of descendants matters.

depending on the application's need the descends (ie. all records created from one record ) must be processed in a certain order.

parent/child associatens ususally result in a tree structure. there are 4 basic ways to traverse a tree, namely:

  • root to leaf, breadth first
  • root to leaf, depth first
  • leaf to root, breadth first
  • leaf to root, depth first

appart from this, applications may have special processing needs and as such an own, custom implementation must be supported.

support >1 processing targets

the same record is processed and added to more than one processing target (PT), such as an 2 diff. search indexs, having diff. structures for diff. tasks.

  • it is possible and likely that the records for the same resource will look differently.
  • diff. pipleines and branches may be executed to get to the PT
  • some PRs of the same data source may only be added to one PT while other are added to several and others are chose not to be processed at all.
complex processing chains

the processing chain (or workflow) may be arbitrarily complex with forks and joins, consisting of several pipelines which may contain any number of pipelets. the path a PR travels is controlled by the rules of pipeline listeners and conditions on their pipelets.
in the cases of some setups and due to the nature of concurrency, the same PR may undergo complete different processing steps and it is not foreseeable which route it takes (though such a case is likely a misconfiguration).

parallel processing branches

in particular, a workflow may also contain parallel processing branches where the same PR is sent several times ( i.e. creating copies of the same PR ) to diff. Qs and/or with diff. JMS properties for consumption by diff. workflows.
a use case for such a scenario is when the items shall be indexed or stored by completely diff. PTs and where the pre-processing steps are different in the two branches.

in this case, it is inherent in the parallel workflow design, that several PRs for the same item exists in the workflow for some period of time. this results automatically in write conflicts and bugs when using a shared record, as is now the case with a persisting BB. therefore in such a case only a transient BB is allowed!

workarounds lifting this limitation are:

  • have a persisting BB per processing branch. an OOB working setup for this is to execute the parallel processing branches on different nodes in a cluster setup or run several SMILA instances on the same box.
  • modify the ID such that it becomes unique for each parallel processing branch
  • implementing the partition concept for the storages, where each parallel branch will have its own partition.
clustering

this means the setup where processing is spread to diff. nodes in a cluster. it also includes usage of several MQs and/or piplines.

Assumption: there is just one instance on just one node to handle all access to the processing target.

oscillating items

these are items that constantly change and where the update intervall usually is smaller then it takes to process them.

Non - Functional

single point of failure

the solution (ideally) doesnt pose an SPOF.

scalability and performance

this is a general requirement and the solution shall outline under this section the impact on performance and where possible bottlenecks are.

Solution Proposals

General Problems

Shared Record Instance via Blackboard

sharing the records via the BB for all processing steps introduces a grave concurrency bug. this is outlined in my mail @ [RE: Message Resequencer :: concept bug detected and general SMILA concurrency problem]

for the time being using a transient BB should solve the problem but is really not the ideal solution. in the end we need partitions for the BB that solve this issue IMO.

Appendix

Abreviations

Abrev Meaning
SN Sequence Number
RS Resquecer Service
FRS Full Resequencer Service
SRS Smart Resequencer Service
Q the Queue as used in a Message Queue
PR processing request, ie to either add or delete a resource and do the needed processing for that. the PR is the combination of JMS message and record.

NOTE: it is legal to have >1 PRs for the same recource on the processing chain. this concept's goal is to bring the PRs into proper order and not neccessarily have just one PR per resource in the processing chain.
NOTE: the term "message" is often used interchangably for this, albeit not quite correct.

PT processing target, basically any pipelet that stores some information on the record other than in Bin- or records storage and where the processing order matters. A search index is an example of this.
CA Config Annotation. A specially named annotation that is attached to the record holding all needed information the RS needs to do its work.

Ideas

  • replace the SN with a more general ComparableObject