Jump to: navigation, search


  • 2009 10 02 major changes to reflect newest insights


this enhancement is tracked thru bug 289995


The Core Problem



Indexing Requirements





Basic Operations

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


compound management, splitting of records






the referenced item may be referenced

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

as a consequence

  • the child item is being processed as a root itself.

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


if the application requires



Parent/Descendants Ordering Requirement

this requirement applies to the case

  • the order of processing of descendants matters.



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


support >1 processing targets



clustering, complex processing chain



single point of failure

the solution (ideally) doesnt pose an SPOF.

scalability and performance


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

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

  • order of PRs for descendents is noted in their respective ConfigAnnotation (e.g. a link to the ID of the preceding or succeding resouce or such)
  • all descendents inherit the SN from their root
  • 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 for
      • 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





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


PT processing target, eg. a full text index


  • replace the SN with a more general ComparableObject