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/basex/BaseXHTTP.java#L405
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 <[email protected]> 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
[email protected]
On Tue, Feb 28, 2017 at 6:22 AM, Marco Lettere <[email protected]> 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" <[email protected]> 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 <[email protected]>
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" <[email protected]>
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.
