I'm running into a problem that perhaps others here can help with.
It appears to be almost identical to the problem reported by "P.C."
on 5 March 2014 under the subject line 'BaseX server.close() "Connection
refused" in Openshift' [1]; the mail record in the basex-talk archive
doesn't show a resolution to P.C.'s problem. The main difference I see
is that P.C. was deploying BaseX under Tomcat 7 on OpenShift, and
I'm using Andy Bunce's quickstart method.
[1] https://www.mail-archive.com/basex-talk%40mailman.uni-konstanz.de/msg03861.html
I'm experimenting with Andy Bunce's BaseX quick-start for OpenShift,
which I like a lot, and I am experiencing the following sequence of
events:
1 Following the instructions at [2], I use rhc to make a new app, add
the Quodatum repository as a remote, merge it into the application
source, and push the result to OpenShift. (Note: no changes made
between the commands "git pull -s recursive -X theirs upstream master"
and "git push origin master". The first time I tried it, I did change
the admin password, but I thought that that might have something to do
with the problem, so I omitted that step for this test.)
[2] https://github.com/Quodatum/openshift-basex-quick-start/
The OpenShift app is now available as promised at the URI indicated in
[1], namely http://TestAPP-CMSMcQ.rhcloud.com/ (except that TestAPP is
not really the name of the app, and CMSMcQ is not the name of the
domain). It's a very nice looking console app.
2 I make some change -- any change -- to a file in the repository.
To keep things simple, I'll add a comment line reading
(: Kilroy was here :)
to the file $app-name/basex/repo/quodatum/basex/env.xqm.
I'm pretty sure I didn't break anything in the env.xqm file in making
the change, and I didn't change anything in any other file.
3 I check the change in to the local git repository:
# confirm that we have not touched anything else
git status
# commit the change
git add basex/repo/quodatum/basex/env.xqm
git commit -m "Vacuous change to env.xqm, just to have something to check in"
4 I attempt to push the change to the deployed app. The response is
shown below (in the extract below, 'Salerno' is the local name of the
machine, 'TestAPP' stands in for the name of the test application, and
"CMSMcQ" for the OpenShift domain -- I've changed them here,
because as can be seen from the log below, the app is currently
open to anyone who knows the default admin userid and password).
Salerno:TestAPP cmsmcq$ git push origin master
Counting objects: 7, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (7/7), 649 bytes | 0 bytes/s, done.
Total 7 (delta 2), reused 0 (delta 0)
remote: Stopping DIY cartridge
remote: HOST: 127.12.13.129
remote: PORT: 15005
remote: DEBUG: true
remote: USER: admin
remote: SERVERHOST: 127.12.13.129
remote: STOPPORT: 15007
remote: SERVERPORT: 15005
remote: PASSWORD: admin
remote: java.io.IOException: Connection failed (port: 15007).
remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:367)
remote: at org.basex.BaseXHTTP.stop(BaseXHTTP.java:180)
remote: at org.basex.BaseXHTTP.<init>(BaseXHTTP.java:94)
remote: at org.basex.BaseXHTTP.main(BaseXHTTP.java:50)
remote: Connection failed (port: 15007).
remote: An error occurred executing 'gear prereceive' (exit code: 1)
remote: Error message: CLIENT_ERROR: Failed to execute: 'control stop' for /var/lib/openshift/568d73d67628e13ca2000004/diy
remote:
remote: For more details about the problem, try running the command again with the '--trace' option.
To ssh://568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'ssh://568d73d67628e13ca2000004@TestAPP-CMSMcQ.rhcloud.com/~/git/TestAPP.git/'
Salerno:TestAPP cmsmcq$
I've logged in to the application using ssh and run the basexhttp stop
command manually, and what one gets then is essentially the same.
I think the root of the matter here is the line reading "remote:
java.io.IOException: Connection failed (port: 15007)", but I'm having
trouble thinking of a fix.
One could imagine that OpenShift doesn't like application code using a
port like 15007. But since it seems to have no trouble with BaseX
using 15005, for the SERVERPORT, that doesn't seem to make sense.
One could suppose that BaseX isn't actually listening on port 15007.
The debugging output produced by -d, however does seems to show that
BaseX knows that port 15007 is the stop port. Or does it? Perhaps it
means only that BaseX has successfully parsed the -s option on the
'stop' command, which reads:
${OPENSHIFT_DATA_DIR}/basex/binbasexhttp -d \
-n ${OPENSHIFT_DIY_IP} -h ${OPENSHIFT_DIY_PORT} \
-p ${PORT_DATABASE} -s ${PORT_STOP} \
-U ${BASEX_USER} -P ${BASEX_PASSWORD} \
stop
which in turn expands to
.../basex/binbasexhttp -d \
-n 127.12.13.129 -h 8080 \
-p 15005 -s 15007 \
-U admin -P admin \
stop
The startup command uses the same values for the -p and -s options, so
it seems plausible that the start command is successfully setting the
port.
Several questions arise in connection with this problem, apart from
the obvious and most important one, namely
Q1 Does anyone reading this list understand where the problem might
lie?
The others that occur to me are:
Q2 Is there a server command or an admin query that will show what
ports a running instance of BaseX is listening to? Or would that be
too broad a security violation? (It would be nice to confirm that BaseX
is actually listening for a stop signal on port 15007.
Q3 A search through the file system of the application shows that logs
are being written to $APPLICATION_HOME/app-root/data/basex/data/.logs/
-- is there any way to find out from a running server what directory
it's writing the logs to, to save the trouble of sshing to the
application server and running
find . -print0 | xargs -0 grep "User was logged in"
or the equivalent? The admin:logs() function was helpful, but it
would have been even more helpful if it had helped me find the logs
directory.
Of course, I see now, looking at the documentation, that logs are
always (? or only by default?) written to $DATABASE_DIRECTORY/.logs --
if I had been confident of knowing what directory was the database
directory in this (still unfamiliar) setup, I would have known where
to look.
Q4 Is there a command or admin-module query that indicates what
directories BaseX regards as the base directory and the database
directory? It could be very helpful, if it's not regarded as too
great a security risk, for users trying to set things up in a new
configuration.
Q5 OpenShift's documentation claims that it really wants application
logs to go into $APPLICATION-HOME/app-root/logs/ -- is there any way
to induce BaseX to write its logs there? The main advantage I can
currently see is that it then becomes possible to examine them with
the OpenShift rhc tools.
Any light anyone can shed on these issues would be very welcome.
Thanks!
Michael Sperberg-McQueen
--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************