Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

SMILA/Documentation/Importing/DeltaCheck

< SMILA‎ | Documentation
Revision as of 06:04, 29 November 2011 by Juergen.schumacher.attensity.com (Talk | contribs) (Clear a single 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

TODO

ObjectStoreDeltaService

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.delta.objectstore/deltastore.properties:

# Object ID configuration for delta entries in object store.
shard.length=2
segment.count=2
segment.length=1
 
# first argument: shard (first characters of record ID digest)
# first argument: segmented record ID digest
key.pattern=%s/%s

See the test case TestDeltaStoreConfiguration.java 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":[
  {
    "source": "web",
    "url": "http://localhost:8080/smila/importing/delta/web"
  },
  {
    "source": "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: more information may be added later ...
{
  "source": "web",
  "url": "http://localhost:8080/smila/importing/delta/web"
}

Clear a single sources

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

Back to the top