Jump to: navigation, search

SMILA/Specifications/ProcessingMessageResequencer


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.

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 OR for a given resource. the outcome of these operations can be discarded -- or even better : processing of these could be suppressed by removing from the Q(s) or pipelines for instance.

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

depending on the application's need the descends (ie. all records created from one record ) must be processed in a cerain 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.

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
CON
  • 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.
PRO
  • simple to implement and has no effect on the API or other logic

Idea 2 - Full Resequencer (FRS)

Synopis: 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)
PRO
  • 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.
CON
  • 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 JMX 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
      ELSE
      ignore and skip operation
      FI
    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
Opinion

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.

Note
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


PRO

  • smarter ;) than FRS

CON

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

Appendix

Abreviations

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.


Ideas

  • replace the SN with a more general ComparableObject