On 7 January 2016 at 18:11, Christian Grün <christian.gruen@gmail.com> wrote:

> Not quite there with BaseX 8.4 beta 5687c30. Now the issue is in BaseXServer
> :
>
> java.io.IOException: Connection failed (port: 15005).
> at org.basex.BaseXServer.stop(BaseXServer.java:317)
> at org.basex.BaseXHTTP.stop(BaseXHTTP.java:191)
> at org.basex.BaseXHTTP.<init>(BaseXHTTP.java:96)
> at org.basex.BaseXHTTP.main(BaseXHTTP.java:52)
> Connection failed (port: 15005).
>
> I see there is another stop using S_LOCALHOST here:
> https://github.com/BaseXdb/basex/blob/master/basex-core/src/main/java/org/basex/BaseXServer.java#L313

Makes sense! If you could check out the latest snapshot again, that’d
be great [1].

Thanks,
Christian

[1] http://files.basex.org/releases/latest/

>
> I think any use of "localhost" will cause issues on OpenShift.
> /Andy
>
> PS:
> I have updated https://github.com/Quodatum/openshift-basex-quick-start to
> use pkill to stop the server for now.
> https://github.com/Quodatum/openshift-basex-quick-start/blob/master/.openshift/action_hooks/stop#L8
>
>
>
>
>
> On 7 January 2016 at 11:52, Christian Grün <christian.gruen@gmail.com>
> wrote:
>>
>> > Makes sense to me. I happy to test an updated version.
>>
>> +1. The updated snapshot is online http://files.basex.org/releases/latest/
>>
>>
>>
>> > /Andy
>> >
>> > On 7 January 2016 at 10:02, Christian Grün <christian.gruen@gmail.com>
>> > wrote:
>> >>
>> >> > I am calling `basexhttp stop` [1] in the OpenShift stop hook.
>> >>
>> >> Thanks ;) In that case, I am wondering what would happen if we
>> >> replaced 'localhost' by SERVERHOST, but if SERVERHOST is an empty
>> >> string. Maybe it would make sense to only go for SERVERHOST if it's
>> >> non-empty and use LOCALHOST otherwise?
>> >>
>> >> Suggestions are welcome. I can easily upload an updated version for
>> >> testing.
>> >> Christian
>> >>
>> >>
>> >> > 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
>> >> > <christian.gruen@gmail.com>
>> >> > 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 <bunce.andy@gmail.com>
>> >> >> 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
>> >> >> > <cmsmcq@blackmesatech.com> 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://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
>> >> >> >> ****************************************************************
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>