Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search


< SMILA‎ | Documentation
Revision as of 07:18, 10 January 2012 by (Talk | contribs) (Show active sources)

Workers for Importing: Delta Check

Delta Checking is about determining if a record has changed since the last import run and needs to be sent to the processing job again, e.g. to update the index.

Worker Description

  • Worker name: deltaChecker
  • Parameters: none
  • Input Slot: recordsToCheck, a recordBulks bucket
  • Output Slot: updatedRecords, a recordBulks bucket. Output maybe empty, if no record needs an update.

The worker calls the DeltaService for each incoming record. The job run id is taken from a task property, while the source ID, record ID and hash code are taken from the record itself. The hash code is expected to be in attribute "_deltaHash" which can contain a single value. Cases are:

  • DeltaService reports record as UPTODATE: record is not added to the output.
  • DeltaService reports record as NEW: record is added to the output.
  • DeltaService reports record as CHANGED: attribute "_update" is set to true and the record is added to the output.
  • "_deltaHash" not set: DeltaService is not called and the record is added to the output.
  • Error in DeltaService: record is not written to output.


The DeltaCheck worker makes use of a DeltaService to check and update the state of a record. The first implementation of this service puts those state entries in the ObjectStore (and hence as separate files in a filesystem, if the filesystem implementation of objectstore is used), which should work well enough for a limited number of records per source.

The keys of the entries are created from the source ID, a '/' character and an entry key created from a digest calculated from the record ID. A small configuration file allows to customize this entry key, which may be necessary to manage a greater number of documents or to make use of advanced features of more sophisticated ObjectStore implementation.

Entry key calculation and configuration

Entries are stored in different "shards". This "sharding" is necessary to make it possible to parallelize the checking for deleted records after the import run has finished: For each shard one task will be generated to find the entries in this shard that have not been visited in this run. The shard part of the entry key is determined by taking the first shard.length characters of the record ID digest. The longer this shard part is the more shards can be created and the more the delete check can be parallelized. The default shard.length is 2 (which yields 256 shards, because the digest is a hexadecimal number).

The rest of the digest can be "segmented", i.e. additional '/' can be added so that not all entries of a shard are stored in a single directory. By default, 1 additional '/' is added after the second character of the digest.

The configuration file is org.eclipse.smila.importing.state.objectstore/

# Object ID configuration for delta entries in object store.
# first argument: shard (first characters of record ID digest)
# second argument: segmented record ID digest

See the test case for examples of the effects of these settings.

DeltaService ReST API

Currently there is only a simple REST API for DeltaService that allows to show which sources have currently entries and delete entries of a single source or all entries.

Show active sources

  • URL: /smila/importing/delta
  • Method: GET
  • Response Code: 200 OK, if successful,
  • Response JSON:
{"sources": [
    "id": "web",
    "url": "http://localhost:8080/smila/importing/delta/web"
    "id": "file",
    "url": "http://localhost:8080/smila/importing/delta/file"

Clear all sources

  • URL: /smila/importing/delta
  • Method: DELETE
  • Response Code: 200 OK, if successful
  • Response JSON: none

Get info about sources

  • URL: /smila/importing/delta/<sourcename>
  • Method: GET
  • Response Code:
    • 200 OK, if successful,
    • 404 NOT FOUND, if source does not have entries currently.
  • Response JSON:

Contains the ID of the source and the number of entries. Usually the number is only estimated because exact counting can take a long time. To force an exact count, add ?countExact=true to the request URL.

  "id": "web",
  "count": "123456"

Clear a single sources

  • URL: /smila/importing/delta/<sourcename>
  • Method: DELETE
  • Response Code: 200 OK, if successful
  • Response JSON: none

Copyright © Eclipse Foundation, Inc. All Rights Reserved.