Revert "Emit a 'stalled' event." (it's misleading)

[bradvogel]

Reverts #254

@manast I realized that this event is actually misleading. New jobs are being processed through processStalledJobs even though they haven't been attempted before.

For example:

1. Worker 1: creates job
2. Worker 2: picks up job in getNextJob() and moves it from 'wait' to 'active'
3. Worker 3: runs processStalledJobs immediately after and gets the job lock before Worker 2 can get it.

I'm testing this in production with 1M+ jobs/day with 20 workers, and seeing more jobs get picked up by processStalledJobs than are picked up by takeLockAndProcessJob.

So if that's the case, this event is misleading.

[manast]

ok. Seems like an interesting insight though. we would need to create a lock when moving the job from wait to active atomically. It should be possible by having a LUA script that implements both operations, I will check this out.

[bradvogel]

Yeah, sounds good. What do you think about merging this though? Until #258 gets fixed.

[manast]

it is un unreleased feature anyway so for my part it is ok to not merging this, nobody will use the version from master anyway (famous last words...).

[bradvogel]

Oh ok, but do you think #258 will be done before you do another npm release (from master)? Just didn't want 'stalled' to confuse people before #258 fixes it :)

[bradvogel]

Addressed in #359. The 'stalled' processor now waits a bit (LOCK_RENEW_TIME) to consider a job stalled.