Skip to main content
Jump to: navigation, search


< SMILA‎ | Specifications
Revision as of 05:35, 7 October 2009 by (Talk | contribs) (split records: updated to cover updated req. section)

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 @

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.

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 exist, however unlikely?

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.

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:


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.)


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.

clustering, complex processing chain

this means the scenario 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.

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.

Idea 1 - Connectivity Consolidation/Resequencer Buffer (CCB, CRB)

There was an idea to handle this case in the connectivity directly with the help of a buffer:

  1. each incoming PR is buffered for a period of time X.
    X is at minimum as long as the longest processing path takes for any given record. In the beginning this value is certainly chosen manually but with evaluating Performance Counters it should be possible to get X automatically or adjust it.
  2. during the time of PR in the buffer, additional PRs for the same rescource are consolidated retaining only the latest to reduce load
  • lag
    all PRs will have the lag of ~2 times X before the index is updated. for mass crawling this might be acceptable but an application using agents usually tries to minimize the period between the resource change and the update of the index.
  • no guarantee that X is sufficient
    delaying processing will reduce the chances of mishaps but there is no guarantee that this is really so.
    the simpliest case of voiding the mechanism even in a simples scenarios, is when the system is for what ever reason under a higher load than usual.
    even more so when the processing chain is more complex such as in a cluster setup to spread processing load over several nodes. in such a scenario we will also need to take into account that some nodes may be down temporarily while retaining the records that were assigned to them.
  • connectivity may have to store a very large amount of items before it can rout them, and these need have to presisted on shutdown etc as well.
  • simple to implement and has no effect on the API or other logic

Idea 2 - Full Resequencer (FRS)

Synopsis: The Resequencer will update the processing target in the exact order as the crawler or agent adds PRs to connectivity.

The processing will be like so:

  1. the router will feed Q1 with PRs.
    For the resequencer to know the order, a new meta info needs to be added -- the sequence number (SN). it must be generated by the agent or by the agent controller
  2. the processing piplines are as normal, but:
    1. w/o the step of calling the processing target
    2. they add the result to a new queue, Q2
  3. the Resequencer will listen on Q2 and picks up all PRs
    1. starting with the first record: feed consecutive chunks of PRs to the processing target
    2. wait for PRs only a max. amount of time (timeout)
  • no processing target can ask for more and correct result is always possible
  • 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.
  • setup is a more complex
  • added overhead due to more steps in the processing chain
  • change to agents or agent controller
  • overkill, b/c there is no need to resequence all PRs, only those with same ID
  • lost PRs will cause the FRS to delay all following PRs up to the timeout

Idea 3 - Smart Resequencer (SRS)

Synopsis: The Smart Resequencer will only resequence the operation on a per record basis.
Rationale: in most cases records are independent of each other and so there is no need of ordering all records.

The processing is very similar to the Full Resequencer:

  1. the router will feed Q1 with PRs.
    For the resequencer to know the order, a new meta info needs to be added -- the sequence number (SN). it must be generated by the agent or by the agent controller
  2. the Resequencer will
    1. get copies of the PRs sent to Q1 via a 2nd Send task on the router, so that it can know what's coming into the processing chain, i.e. it maps IDs to SNs
      these PR copies just need to contain the id and the SN.
    2. enhancement:
      the SRS could remove obsolete older PRs from Qs to stop them from being processed further.
      this needs the hash and SN to be present as a JMS property for the selector and doesnt cover the case of records currently processed in a pipline.
  3. the processing piplines are as normal, but:
    1. w/o the step of calling the processing target
    2. they add the result to a new queue, Q2
  4. the Resequencer will listen on Q2 and pick up all PRs. for each PR:
    1. IF its SN matches the one in the map THEN
      call the index service for the record
      ignore and skip operation
    2. remove ID from map

Impl Basics

  • implemented as ProcessingService
  • records are sent to it with the command/process mode REGISTER and SEQUENCE
  • SN and process mode are given as annotation on the record, called the Config Annotation (CA). this is the same way as with the lucen service. (i first wanted to do this as JMS props but they are not accessible in a ProcessingService)
  • map may be in memory or a persisting solution may be implemented/chosen.
    IMO the amount of records held im momory should be relativly small, only to the amount of what is in the processing chain. (hm, that can be a lot, since connectivity is not pausing crawlers and agents (yet) if there is much in the MQ)

Meeting Requirements

The general ones should be sufficeiently clear from the functional description of the SRS. here come now the furhter ones:

split records

compound and aggregation are handled the same way, like so:

the processing step splitting the record is responsible for the the following:

  • all descendants inherit the SN from their root
  • if internal ordering:
    order of PRs for descendants is noted in their respective ConfigAnnotation (e.g. a link to the ID of the preceding or succeeding resource or such)
  • register the split records with the SRS
  • possibly deregister the root and/or intermediate PRs if these are not processed further

the SRS will

  • collect all PRs belonging to the tree of split PRs until it is complete
    • missing PRs:
      • timeout
      • config on how to continue with non-complete trees: {all or nothing, sequence incomplete}
>1 Processing Targets

this can be supported in diff. ways. both have in common:

  1. sending the PR to any of the PTs is done thru the SRS by calling it with the SEQUENCE command (this is just a generalization of the basic concept and repeated here for clarity)
  2. the SRS needs to know how many (potential) PTs there are for a resource (determine by the ID) and when processing really has finished for a given ID.
  3. each SEQUENCE and UNREGISTER command will reduce the count, when it reaches 0 all PRs have reached their PT and the ID can be removed from the map.
idea 1 - SRS ID rules
  • the config of the SRS contains rules or conditions that determine the count.
  • it starts with that count wich is computed on REGISTRATION.
idea 2 - processing steps control counter
  • processing steps take care of in- and decerementing the counter in the normal processing chain by using the REGISTER and UNREGISTER commands to reflect additional or obsolte PTs

i like idea 2 better b/c it puts the config of the SRS in the same place that also controls the flow of PRs anyhow. it is just a matter of including an SRS call with the respective command.
in contrast, idea 1 would mean that we have to:

  • duplicate the processing chain logic in some other place
  • implement a rule/condition engine and config.
clustering, complex processing chain
  • complex processing chains are possible as already described in other places. the SRS just needs to be placed in front of the PT and called in the flow of things
  • resequencing in a cluster scenario works OOB as the output of the SRS is just directed anyway to the Q that feeds the PT (or any another processing step).
    It matters little if that sits on on another node. the key here lies in the design of the processing chain to not mix up the order again, such as having >1 listerns on the Output-Q.

i think the SRS will even work if the assumption that each PT has only one instance and node that solely accesses the PT holds not true. a setup like this will then segment all PRs by some scheme that depends on the ID and then the SRS has only to resequence the one segement and thus: all is well.

single point of failure

hm. this is a tough one as the singelnes is inherent. i have no clue yet, how to solve this, other than to use a fail-over solution. i guess, just as the PT itself, it needs to be monitored closely to detect malfunctios and in a cluster scenario where this case is required the SRS lives.

Cases introduced thru this solution

this section lists cases and problems that need to be covered that are introduced thru the solution itself. some of the items listed here will also apply to the FSR!!

  • handling of unregistered records
    what happens when SEQUENCING a PR that is already @ count 0 /not existing.
  • what to do with recods that miss needed config data?
    handling depends on the process mode:
    • SEQUENCE: error as default , but outcome could be config'able such as : DLQ, any other Q
    • REGISTER: error
  • overflow of the SN
    a reset signal must be sent to SRS


  • smarter ;) than FRS


  • see also almost all CONS @ FRS
  • ossilating resources (that constantly change) will never make it into the index.

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.



Abrev Meaning
SN Sequence Number
RS Resquecer Service
FRS Smart Resquecer Service
SRS Smart Resquecer 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, eg. a full text index
CA Config Annotation. A specially named annotation that is attached to the record holding all needed information the RS needs to do its work.


  • replace the SN with a more general ComparableObject

Back to the top