On 18 September 2017 at 22:53, VERMEULEN Olivier < olivier.vermeu...@murex.com> wrote:
> Hello, > > Following up on Adel's email. > I took a look at the initiateShutdown endpoint you mentioned. > I tested it and it seems to work but I don't see it in any documentation, > not even in the broker apidocs. > Is there a reason for that? Is this feature officially supported? > Since the code was introduced back in 2015, it has been marked with a meta data description "Initiates an orderly shutdown of the Broker." This text *should* show in the API docs for the broker operations. Since there are no parameters to pass, there is no further documentation. The feature is and remains supported. > And one more question, why is the broker's qpid.stop script not using the > same graceful mechanism? > The qpid.stop script hasn't seen any changes (other than a blanket update to all shell scripts which use bash) since 2009. Since the REST API *should* use authentication, and may even be disabled (or on a non standard port), I don't think it could be used by the standard stop script anyway. -- Rob > > Thanks, > Olivier > > -----Original Message----- > From: Adel Boutros [mailto:adelbout...@live.com] > Sent: jeudi 14 septembre 2017 18:34 > To: users@qpid.apache.org > Subject: Re: [Qpid Java Broker 6.0.4] [Linux] Stop script keeps trying to > kill a dead broker > > Thank you Rudyy, > > > Unfortunately, I don't have any extra information to share. May be the > stop script should be updated to check output of kill command to confirm > the process is still here. > > > Regards, > > Adel > > ________________________________ > From: Oleksandr Rudyy <oru...@gmail.com> > Sent: Friday, September 8, 2017 1:46:54 PM > To: users@qpid.apache.org > Subject: Re: [Qpid Java Broker 6.0.4] [Linux] Stop script keeps trying to > kill a dead broker > > Hi Adel, > Thanks for reporting the issue. The qpid.stop script might need more love, > though, after sending SIGTERM or SIGKILL event to the broker process, it > waits for 1 second and than verifies that process with given PID is still > reported by ps (ps -e | grep $1 | wc -l). If process is not reported, no > further attempts to send termination signal is made. It seems that in your > case the Broker process was present in process table. I could be that it > became defunctional. You mentioned that it happens randomly. Do you know > what what happens with the broker and broker jvm? Is broker shutdown > gracefully? If not, it could be an indication of issue with broker shutdown > or jvm exit. > > Additionally, I would like to point out that you can call Broker REST API > to shutdown the broker (/api/latest/broker/initiateShutdown). As > operation name suggests, it does not shutdown broker immediately but rather > starts the broker shutdown process and exits. If broker restart is > required, a restart operation can be invoked via REST API as well > (/api/latest/broker/restart). > > Kind Regards, > Alex > > > On 6 September 2017 at 17:21, Adel Boutros <adelbout...@live.com> wrote: > > > Hello, > > > > > > In one of our tests, we were having a random failure. It seems we > > cannot stop a broker correctly. > > > > We have a started broker and we call "bin/qpid.stop $BROKER_PID" to > > stop it. It seems to work from the first time but maybe not fast > > enough because the script keeps trying to kill the broker which is > actually dead. > > > > > > Is this a know issue? Is it fixed on a newer version? > > > > > > Command output > > > > =============== > > > > Waiting 1 second for 514 to exit > > broker/bin/qpid.stop: line 49: kill: (514) - No such process Waiting 1 > > second for 514 to exit > > broker/bin/qpid.stop: line 41: kill: (514) - No such process Waiting 1 > > second for 514 to exit > > broker/bin/qpid.stop: line 41: kill: (514) - No such process Waiting 1 > > second for 514 to exit Stopped trying to kill process: 514 Attempted > > to stop 2 times > > > > > ******************************* > > This e-mail contains information for the intended recipient only. It may > contain proprietary material or confidential information. If you are not > the intended recipient you are not authorised to distribute, copy or use > this e-mail or any attachment to it. Murex cannot guarantee that it is > virus free and accepts no responsibility for any loss or damage arising > from its use. If you have received this e-mail in error please notify > immediately the sender and delete the original email received, any > attachments and all copies from your system. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
