Hello, I have some news on this issue. I tracked down the interaction between the two instances of BaseXHTTP dring the shutdown process. I've found out that the issue is located in the if clause located at [1].
The code looks like that:
if(stopFile.exists()) { socket.close(); jetty.stop(); HTTPContext.close(); Prop.clear(); if(!stopFile.delete()) { context.log.writeServer(LogType.ERROR, Util.info(FILE_NOT_DELETED_X, stopFile)); } break; }
For some reason I'm unable to explain, in our configuration HTTPContext.close(); causes the BaseXHTTP server process to immediately exit. Thus, by skipping Prop.clear() and stopFile.delete(), the infinite looping behaviour of the stopping script is generated. Just as a proof of concept: rewriting the code as shown below solved the issue and both instances are shut down as usual.
if(stopFile.exists()) { socket.close(); jetty.stop(); Prop.clear(); if(!stopFile.delete()) { context.log.writeServer(LogType.ERROR, Util.info(FILE_NOT_DELETED_X, stopFile)); } HTTPContext.close(); break; }
Of course I don't know why HTTPContext.close() terminates the process and whether the second code is introducing some other issue but I hope that this info is useful for the BaseX staff to solve the problem. Regards, Marco.
[1] https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/bas...
On 28/02/2017 13:43, Christian Grün wrote:
Thanks for the additional confirmation. I will definitely try to get this reproduced soon.
On Tue, Feb 28, 2017 at 1:03 PM, Tim Thompson timathom@gmail.com wrote:
I've also noticed similar behavior in version 8.6 on Ubuntu 14.04. If I start the server in one terminal window and then run the stop script in a separate window, the server does stop, but the basexhttpstop script keeps hanging.
-- Tim A. Thompson Metadata Librarian (Spanish/Portuguese Specialty) Princeton University Library
www.linkedin.com/in/timathompson tat2@princeton.edu
On Tue, Feb 28, 2017 at 6:22 AM, Marco Lettere m.lettere@gmail.com wrote:
No Christian, really nothing special. Everything used to work neatly until Saturday when we tried 8.6.1 by just unzipping and launching. Btw we use Java 1.8.0_121 on both win7 and Ubuntu 16.04. Latest news same happens on Mac Sierra with Java 1.8.0_121. We've seen that there have been some commits recently on that parte of the code but I don't have a connection in my PC now ti check it in depth. Sorry. Ciao, Marco.
Il 28 feb 2017 10:49 AM, "Christian Grün" christian.gruen@gmail.com ha scritto:
Hi Marco,
Hm, so it seems that the file is not deleted by the shutdown process. I cannot reproduce this with the zip distribution on both Window 10 and Ubuntu; have you changed anything in the configuration files?
Christian
On Tue, Feb 28, 2017 at 9:38 AM, Marco Lettere m.lettere@gmail.com wrote:
Hi Christian, -d doesn't add much info. But we've found out that the shutdown script hangs on a file BasexHTTP8985 in the tmp directory. This happens btw on Windows 7 too. If we delete the file, while basexhttpstop is blocked, then basexhttpstop ends immediately and correctly. If we ctrl-c basexhttpstop then at the next shutdown we get a FileAlreadyExists exception.
Thanks for tour support. Marco.
Il 28 feb 2017 12:05 AM, "Christian Grün" christian.gruen@gmail.com ha scritto:
Hi Marco,
Could you please report back to us what exactly is output on the two shells? Ideally, please run both commands with the -d flag.
Thanks in advance, Christian
PS: Does it work with 8.6, 8.5.3 or older versions?
> I just downloaded Basex861.zip for Linux (Ubuntu 16.04 the host). > > Unizipped and started basexhttp. Everything ok. > > In another shell I launch basexhttpstop which correctly shuts down > the > server started before. But basexhttpstop itself does not terminate. > > This is causing some headache in our scripts that launch and stop > several > instances. > > Any clue? > > Thanks a lot, > > Marco. >