SMILA/Specifications/ProcessingMessageResequencer

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

• Connectivity Consolidation Buffer (CBC)
• Full Resequencer (FRS)
• Smart Resequencer (SRS)
• Skip Pipelet (SP)
• 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 @ [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