{"_id":"55ed8ce82e66b621009941c3","project":"55e94ebde5d0c623003ed868","version":{"_id":"55e94ebee5d0c623003ed86b","project":"55e94ebde5d0c623003ed868","__v":1,"createdAt":"2015-09-04T07:56:46.272Z","releaseDate":"2015-09-04T07:56:46.272Z","categories":["55e94ebee5d0c623003ed86c"],"is_deprecated":false,"is_hidden":false,"is_beta":true,"is_stable":true,"codename":"","version_clean":"0.3.0","version":"0.3.0"},"__v":2,"user":"55e94db887e942230032e40d","category":{"_id":"55e94ebee5d0c623003ed86c","pages":["55e94ebfe5d0c623003ed86e","55ed7fdadf21af2b009e217d","55ed86db2e66b621009941a6","55ed879428d7c33700de00e1","55ed88392e66b621009941a9","55ed885cec4c3e3900b75611","55ed88ba2e66b621009941ab","55ed8caba872a80d00acff5d","55ed8ce82e66b621009941c3","560d5df697a0a32f006e9de9","566ff8f33a32d20d00c45b37","5670195e81801f0d00802e1c"],"version":"55e94ebee5d0c623003ed86b","__v":12,"project":"55e94ebde5d0c623003ed868","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-09-04T07:56:46.830Z","from_sync":false,"order":9999,"slug":"documentation","title":"Documentation"},"githubsync":"","updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-09-07T13:11:04.130Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":8,"body":"Each worker connects to the actual leader broker with a single TCP connection over which are multiplexed deliveries of messages.\n\nIf the TCP connections goes down for any reason the node must look for a new leader broker and retry the connection.\n\nWhen a node boots it created an unique id (\"process id\").\n\nFrom the broker point of view if a node does not reconnect within a configurable amount of time it is considered dead, and the actual worker process id cannot be used any more.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Status of a Workers\"\n}\n[/block]\nA Worker could be in the following states:\n\n  * **CONNECTED**: a valid TCP connection is active\n  * **DISCONNECTED**: no TCP connection is active, but there are tasks assigned to the node\n  * **DEAD**: no connection is present for a long time\n\nWhen a Node transitions from the DISCONNECTED to the DEAD status then recovery is scheduled for each task present on the node (based on the retry policy of the task).","excerpt":"","slug":"worker-lifecycle","type":"basic","title":"Worker Lifecycle"}
Each worker connects to the actual leader broker with a single TCP connection over which are multiplexed deliveries of messages. If the TCP connections goes down for any reason the node must look for a new leader broker and retry the connection. When a node boots it created an unique id ("process id"). From the broker point of view if a node does not reconnect within a configurable amount of time it is considered dead, and the actual worker process id cannot be used any more. [block:api-header] { "type": "basic", "title": "Status of a Workers" } [/block] A Worker could be in the following states: * **CONNECTED**: a valid TCP connection is active * **DISCONNECTED**: no TCP connection is active, but there are tasks assigned to the node * **DEAD**: no connection is present for a long time When a Node transitions from the DISCONNECTED to the DEAD status then recovery is scheduled for each task present on the node (based on the retry policy of the task).