)]}'
{
  "commit": "d00b981445c03622497088eb872059ab4f48b298",
  "tree": "90cfebe35ace498d0d849cad8388b1bbf06e5772",
  "parents": [
    "f63efa786fec5cc40e6c6193470399da99385abf"
  ],
  "author": {
    "name": "Nick Vatamaniuc",
    "email": "vatamane@apache.org",
    "time": "Fri Mar 10 01:15:47 2017 -0500"
  },
  "committer": {
    "name": "Nick Vatamaniuc",
    "email": "vatamane@apache.org",
    "time": "Fri Mar 10 01:15:47 2017 -0500"
  },
  "message": "Prevent replicator manager change feeds from getting stuck\n\nSwitch them them from `longpoll` to `normal`\n\nThis would prevent them being stuck. That could happen if more than one\n`resume_scan` message arrives for the same shard. The first time a longpoll\nchangef feed would finish and end sequence is checkpointed. But if another\nresume_scan arrives and database hasn\u0027t changed then the longpoll change\nfeed would hang until db is updated.\n\nThe reason there would be multiple `resume_scan` messages is because there\nis a race condition between db update handler and scanner component. They are\nboth started asynchronously roughly at the same. Scanner finds new shard while\ndb handler notices changes for those shards. If shards are modified quickly\nafter they are discovered by the scanner both of those components would issue\na resume_scan.\n\nThe effect of this would be more pronounced if there are a large number of\n_replicator shards and constant db creation/deletion/updates.\n\nCOUCHDB-2964\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "2bcad69f1afd7088003c8e8c3dc34457d378806d",
      "old_mode": 33188,
      "old_path": "src/couch_replicator_manager.erl",
      "new_id": "85dd428f2b423973133810f9781c213a2d22b7cc",
      "new_mode": 33188,
      "new_path": "src/couch_replicator_manager.erl"
    }
  ]
}