Hi Bobby, Thanks for the response. I have created JIRA https://issues.apache.org/jira/browse/STORM-2299. I will try to take look at it. I may ask some information if needed.
Regards, Sachin From: Bobby Evans <ev...@yahoo-inc.com<mailto:ev...@yahoo-inc.com>> Date: Tuesday, 17 January 2017 at 9:16 PM To: Sachin Pasalkar <sachin_pasal...@symantec.com<mailto:sachin_pasal...@symantec.com>>, "dev@storm.apache.org<mailto:dev@storm.apache.org>" <dev@storm.apache.org<mailto:dev@storm.apache.org>> Subject: Re: Stop user from killing topology before X (configured) amount of time I would like to add that it would be good to have an admin override on this. If someone accidentally makes the wait time 100 mins instead of 100 seconds, it would be good to have an admin be able to really truly kill it faster. - Bobby On Tuesday, January 17, 2017, 9:44:08 AM CST, Bobby Evans <ev...@yahoo-inc.com<mailto:ev...@yahoo-inc.com>> wrote: In order to kill a topology with no wait period the operator needs to supply extra arguments `-w 0` or the code needs to be a few lines longer to pass in the KillOptions with a 0 timeout. If you want a configured minimum timeout for a given topology I think that would be perfectly fine. We do not currently support that, but please file a JIRA and hopefully someone can take a look at supporting it. You can probably do a lot of the work yourself if you want to. The function you care about is here https://github.com/apache/storm/blob/51c8474143b0081ff0522b0367f3efdba2689089/storm-core/src/jvm/org/apache/storm/daemon/nimbus/Nimbus.java#L2573-L2595<https://clicktime.symantec.com/a/1/hMFfR0x0xhEPmnLkHrzWh1uM1FSHoBzqUa0fgE8KPhI=?d=MS-UWN_vi-ZagJt0xU9IbvMa_Sn5eMGVNdZjVChgjfQhVEoPckk5VmUO2oDaDYkTCwElmne6IQyPHIs9Xsx084v1kwUi12v19jPqFi2LdGRZlDEGKeq1Gmvap2me3KrdZ8XQlgz9QYP6tI9JZQWmvDxUG05nMBb-jaYIpO18xE0MHYoRK2-h_USW97P7EB7pfMIvXZl6w-WWJdIDa9H2Eyc1tV1KXa86gDMqWmas7nf3C5nXp1-PHc6f6iQ3IwxC5aybtUIeNAppWBP8OYeXZ2wiQkzAplSlfDw4ITeSXx0MDEla47QjArk-uAlgsRCv7i-i746Yt2NXxUgpMd2HHhTQqrJZGTV9QWQlgSG0K47u2TK1xmxZNzdzjHK_wrJ07ilUKeIVsThyyA_Jm7wg4Qwwf1dwnkVnt6zYEh3Ze6kE&u=https%3A%2F%2Fgithub.com%2Fapache%2Fstorm%2Fblob%2F51c8474143b0081ff0522b0367f3efdba2689089%2Fstorm-core%2Fsrc%2Fjvm%2Forg%2Fapache%2Fstorm%2Fdaemon%2Fnimbus%2FNimbus.java%23L2573-L2595> and it really would be mostly inserting a check probably after this line https://github.com/apache/storm/blob/51c8474143b0081ff0522b0367f3efdba2689089/storm-core/src/jvm/org/apache/storm/daemon/nimbus/Nimbus.java#L2583<https://clicktime.symantec.com/a/1/vgKlrHDYwUXdyawdaYGs46xwhu5329aNEdr3WD7HDrE=?d=MS-UWN_vi-ZagJt0xU9IbvMa_Sn5eMGVNdZjVChgjfQhVEoPckk5VmUO2oDaDYkTCwElmne6IQyPHIs9Xsx084v1kwUi12v19jPqFi2LdGRZlDEGKeq1Gmvap2me3KrdZ8XQlgz9QYP6tI9JZQWmvDxUG05nMBb-jaYIpO18xE0MHYoRK2-h_USW97P7EB7pfMIvXZl6w-WWJdIDa9H2Eyc1tV1KXa86gDMqWmas7nf3C5nXp1-PHc6f6iQ3IwxC5aybtUIeNAppWBP8OYeXZ2wiQkzAplSlfDw4ITeSXx0MDEla47QjArk-uAlgsRCv7i-i746Yt2NXxUgpMd2HHhTQqrJZGTV9QWQlgSG0K47u2TK1xmxZNzdzjHK_wrJ07ilUKeIVsThyyA_Jm7wg4Qwwf1dwnkVnt6zYEh3Ze6kE&u=https%3A%2F%2Fgithub.com%2Fapache%2Fstorm%2Fblob%2F51c8474143b0081ff0522b0367f3efdba2689089%2Fstorm-core%2Fsrc%2Fjvm%2Forg%2Fapache%2Fstorm%2Fdaemon%2Fnimbus%2FNimbus.java%23L2583> to be sure the waitAmount is >= the configured minimum. - Bobby On Tuesday, January 17, 2017, 1:28:32 AM CST, Sachin Pasalkar <sachin_pasal...@symantec.com<mailto:sachin_pasal...@symantec.com>> wrote: Currently user can kill topology directly without waiting for some amount of time so that all inflight messages will get processed. For example, storm is writing to file & user kills topology, file is not closed or moved to proper location. We need to educate operation guys to do the right things also there are some chances that it will be not followed causing system to go in inconsistent state. Can we set mandatory timeout (configurable) when user kills storm topology? User should not be allowed kill topology with time less than mentioned time. Some case: 1) If topology is long running don't allow user to kill but time not less than mentioned one 2) If topology is just deployed allow him to kill instantly (as it might be some mistake) 3) Handle same cases from command-line. Thanks, Sachin
