Hi Christian,

I am calling `basexhttp stop` [1] in the OpenShift stop hook. This is part
of OpenShift's application lifecycle management [2]
`stop` and `start` are automatically invoked after a code change is
committed.

My understanding is in the OpenShift environment "localhost" is not
resolved/allowed. The environment supplied value must be used, in this
case `${OPENSHIFT_DIY_IP}`
[3]

/Andy

[1]
https://github.com/Quodatum/openshift-basex-quick-start/blob/master/.openshift/action_hooks/stop
[2] https://developers.openshift.com/en/managing-action-hooks.html
[3] https://developers.openshift.com/en/diy-overview.html



On 7 January 2016 at 08:46, Christian Grün <[email protected]>
wrote:

> Hi Andy,
>
> >> I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe this
> needs to be HOST or SERVERHOST.
> >>
> >>
> https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/basex/BaseXHTTP.java#L375
>
> This code is currently called if the BaseX HTTP server is called via
> the 'basexhttp' start script (or via 'new BaseXHTTP()' in Java) and
> the 'stop' argument [1]. Are you using these calls somewhere in your
> code?
>
> Christian
>
> [1] http://docs.basex.org/wiki/Command-Line_Options#HTTP_Server
>
>
>
> On Thu, Jan 7, 2016 at 1:18 AM, Andy Bunce <[email protected]> wrote:
> > Hi Michael,
> >
> > I get the same result.
> > I believe the problem is [1]. S_LOCALHOST is "localhost". Maybe this
> needs
> > to be HOST or SERVERHOST.
> >
> > /Andy
> >
> >
> https://github.com/BaseXdb/basex/blob/master/basex-api/src/main/java/org/basex/BaseXHTTP.java#L375
> >
> > On 6 January 2016 at 21:54, C. M. Sperberg-McQueen
> > <[email protected]> wrote:
> >>
> >> 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://
> [email protected]/~/git/TestAPP.git/
> >>    ! [remote rejected] master -> master (pre-receive hook declined)
> >>   error: failed to push some refs to
> >> 'ssh://
> [email protected]/~/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
> >> ****************************************************************
> >>
> >>
> >>
> >>
> >
>

Reply via email to