Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Process does not always exit on completion of data ingestion #24

Closed
heffergm opened this issue Nov 17, 2014 · 4 comments
Closed

Process does not always exit on completion of data ingestion #24

heffergm opened this issue Nov 17, 2014 · 4 comments
Assignees
Labels

Comments

@heffergm
Copy link

Node process continues to run and output to stderr, but by all appearances no counters are incremented in the log, leaving the impression that there's no data left to process.

Sample extract where I've seen this: https://s3.amazonaws.com/metro-extracts.mapzen.com/rome_italy.osm.pbf

@aberrios85
Copy link

+1

Seen same issue, stops pelias chef recipe completing.

Seen on imports of west-yorkshire and south-yorkshire osm.pbf GBR imports.

@cesozgen
Copy link

Any update or workaround to this?

@sevko sevko self-assigned this Jan 26, 2015
@sevko sevko added the bug label Jan 26, 2015
@sevko
Copy link
Contributor

sevko commented Feb 5, 2015

@cesozgen , yes, a quick and very dirty hack: change the module.exports = stats; in /stream/stats.js to module.exports = through.obj;. This will prevent the OSM parser from spitting out ingestion stats (though you'll still see elasticsearch indexer stats), but the process will exit. Here's the reason why:

tl;dr, the OSM ingestion statistics-logging setInterval() isn't getting clearInterval()'d.

The stats module exports a stream that tracks the number of records that pass through, and stores the total number of such streams instantiated globally. The counter is incremented on pipe and decremented on unpipe events respectively: the interval gets set when the first pipe's created and torn down when the last one's closed, which is inferenced from the value of the counter. It turns out that the number of pipes and unpipes detected is !=, meaning that the counter doesn't drop to 0 like it should.

@missinglink
Copy link
Member

resolved by #27

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants