[jira] Commented: (COUCHDB-393) Cannot discover currently running http port if ini file specifies port 0
[ https://issues.apache.org/jira/browse/COUCHDB-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883706#action_12883706 ] Chris Anderson commented on COUCHDB-393: Benoit's patch looks good to me. I'd be happy to see it in 1.0. Care to commit it? > Cannot discover currently running http port if ini file specifies port 0 > > > Key: COUCHDB-393 > URL: https://issues.apache.org/jira/browse/COUCHDB-393 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 0.9 > Environment: Ubuntu 9.04 >Reporter: Stuart Langridge >Assignee: Noah Slater >Priority: Blocker > Fix For: 0.12 > > Attachments: couch_uri.patch, couchctl.patch > > > It is currently not possible, if the ini file specifies port 0 as the http > port (so that the OS chooses a random port) to discover which port the OS > actually chose. > It would be nice if the currently running port was made available in the > statusline output (couchdb -s), but a log statement would be adequate; some > way that an external script can discover which port a running CouchDB is > listening on. > Edited discussion from #couchdb: > aquarius: well at a glance it appears couch_http passes the 0 to > mochiweb_http which passes it to the mochiweb_socket_server, which passes it > to gen_tcp, an erlang module that lets the underlying OS assign it. > mochiweb_socket_server then grabs that port and stores it. It has a get > method to retrieve properties but that needs to be exposed to mochiweb_http > so it would take a little work to do it. It's probably a JIRA ticket, unless > someone else sees a quicker approach > bitdiddle: you got that far and didn't find it? > davisp: is there a better way to find the port? > oh, is that not the bind port? > I was just thinking a log statement > davisp: the problem is if you specify 0 as the bind port (so the > OS chooses a port), how do you find out what was chosen? > aquarius: you have to look at the port returned by the socket > aquarius: in other words, CouchDB was never written to do that > AFAIK > davisp: I found it, just needs some work to expose it > aquarius: and by do that, I mean, we never put in a statement to log > that > mochiweb_http is the module that needs to bubble it up > davisp: I don't really mind whether it's a log statement or it's > exposed to couchdb -s (the latter seems tidier to me, but whichever), I just > want to be able to start couch on port 0 and then later find out which port > got chosen :) > aquarius: for the time being you can use something like netstat or > lsof, but we'll get a log statement in there or something -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 1.0 Vote
> > Sorry I didn't see this patch before I implemented a continuous = true > checkbox (see trunk now) if your patch is preferable then we can swap it for > mine. Should I take the time to apply and test, or is Trunk good? > Oh noes! :) Seriously though, that's good. Just close #489 Cheers, -- David Coallier
Re: 1.0 Vote
On Jun 29, 2010, at 11:41 AM, David Coallier wrote: > On 29 June 2010 18:41, Adam Kocoloski wrote: >> On Jun 29, 2010, at 10:20 AM, J Chris Anderson wrote: >> >>> For trunk, I think there are a couple of small patches that Adam wants to >>> hold back for 1.1. >> >> Not a big deal, everything I committed to trunk is pretty stable and tested >> in production. I tagged those commits as 1.1 because they weren't strictly >> bugfixes, but given that we're adding other performance improvements in 1.0 >> I'd be happy to have them included. > > I'd like to include https://issues.apache.org/jira/browse/COUCHDB-489 > in 1.0 as well. > > Depending on when the 1.0 date is "planned" to be, I'll free some time > up from work to fix this once and for all. > Sorry I didn't see this patch before I implemented a continuous = true checkbox (see trunk now) if your patch is preferable then we can swap it for mine. Should I take the time to apply and test, or is Trunk good? Chris > -- > David Coallier
Re: 1.0 Vote
On 29 June 2010 18:41, Adam Kocoloski wrote: > On Jun 29, 2010, at 10:20 AM, J Chris Anderson wrote: > >> For trunk, I think there are a couple of small patches that Adam wants to >> hold back for 1.1. > > Not a big deal, everything I committed to trunk is pretty stable and tested > in production. I tagged those commits as 1.1 because they weren't strictly > bugfixes, but given that we're adding other performance improvements in 1.0 > I'd be happy to have them included. I'd like to include https://issues.apache.org/jira/browse/COUCHDB-489 in 1.0 as well. Depending on when the 1.0 date is "planned" to be, I'll free some time up from work to fix this once and for all. -- David Coallier
Re: 1.0 Vote
On Jun 29, 2010, at 10:20 AM, J Chris Anderson wrote: > For trunk, I think there are a couple of small patches that Adam wants to > hold back for 1.1. Not a big deal, everything I committed to trunk is pretty stable and tested in production. I tagged those commits as 1.1 because they weren't strictly bugfixes, but given that we're adding other performance improvements in 1.0 I'd be happy to have them included. Thanks for checking, Adam
Re: 1.0 Vote
On 29 Jun 2010, at 16:40, Benoit Chesneau wrote: > Noah was suggesting to give this info from couch-s, but it's not an > easy patch and could wait next release imo. What is the deadline > before couch 1.0 ? Shouldn't we wait for erlang R14B and then having > ful support for windows version ? Or windows version will be 1.1 ? Features in 1.0 should be bedded. Windows support has not been broadly tested, so seems to fail this. Is R14B likely to cause apropos problems?
Re: 1.0 Vote
On Tue, Jun 29, 2010 at 4:20 PM, J Chris Anderson wrote: > > On Jun 26, 2010, at 7:00 PM, J Chris Anderson wrote: > >> [snip] >> >> That's correct Mark. Trunk is what you want (although there are a few >> patches that might not make 1.0) >> >> I plan to start a thread for what to keep back for 1.1 and a thread for >> anything that should be un-backported from 0.11.x, to clear up the last >> questions. > > So I went through both trunk and 0.11.x looking for things that are out of > place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is > ready for release. > Would like to put the patch from COUCHDB-393 before we release though. https://issues.apache.org/jira/browse/COUCHDB-393 This patch is needed to port easily cocuhdb-desktop to other platform or any other alternative. It could also be used for some operations. Noah was suggesting to give this info from couch-s, but it's not an easy patch and could wait next release imo. What is the deadline before couch 1.0 ? Shouldn't we wait for erlang R14B and then having ful support for windows version ? Or windows version will be 1.1 ? - benoit
Re: 1.0 Vote
If we're branching and tagging from trunk, then trunk. On 29 Jun 2010, at 15:48, till wrote: > On Tue, Jun 29, 2010 at 4:38 PM, Noah Slater wrote: >> >> On 29 Jun 2010, at 15:20, J Chris Anderson wrote: >> >>> So I went through both trunk and 0.11.x looking for things that are out of >>> place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is >>> ready for release. >>> >>> For trunk, I think there are a couple of small patches that Adam wants to >>> hold back for 1.1. There is also the Windows stuff, which looks like we >>> should wait for, before cutting 1.0. >> >> I am waiting for a go command, so just let me know. >> >> Please can everyone check that "make distcheck" is working for them. >> >> Let's try to avoid the test failures again for this release. > > What's the tag to use? trunk?
Re: 1.0 Vote
On Jun 29, 2010, at 7:38 AM, Noah Slater wrote: > > Please can everyone check that "make distcheck" is working for them. > > Let's try to avoid the test failures again for this release. `make distcheck` failed with a list of all the .patch files and stuff laying around my CouchDB trunk checkout. Trying it on a pristine checkout yields: == apache-couchdb-0.12.0a958998 archives ready for distribution: apache-couchdb-0.12.0a958998.tar.gz == Chris
Re: 1.0 Vote
On Tue, Jun 29, 2010 at 4:38 PM, Noah Slater wrote: > > On 29 Jun 2010, at 15:20, J Chris Anderson wrote: > >> So I went through both trunk and 0.11.x looking for things that are out of >> place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is >> ready for release. >> >> For trunk, I think there are a couple of small patches that Adam wants to >> hold back for 1.1. There is also the Windows stuff, which looks like we >> should wait for, before cutting 1.0. > > I am waiting for a go command, so just let me know. > > Please can everyone check that "make distcheck" is working for them. > > Let's try to avoid the test failures again for this release. What's the tag to use? trunk?
Re: 1.0 Vote
On 29 Jun 2010, at 15:20, J Chris Anderson wrote: > So I went through both trunk and 0.11.x looking for things that are out of > place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is > ready for release. > > For trunk, I think there are a couple of small patches that Adam wants to > hold back for 1.1. There is also the Windows stuff, which looks like we > should wait for, before cutting 1.0. I am waiting for a go command, so just let me know. Please can everyone check that "make distcheck" is working for them. Let's try to avoid the test failures again for this release.
Re: 1.0 Vote
On Jun 26, 2010, at 7:00 PM, J Chris Anderson wrote: > [snip] > > That's correct Mark. Trunk is what you want (although there are a few patches > that might not make 1.0) > > I plan to start a thread for what to keep back for 1.1 and a thread for > anything that should be un-backported from 0.11.x, to clear up the last > questions. So I went through both trunk and 0.11.x looking for things that are out of place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is ready for release. For trunk, I think there are a couple of small patches that Adam wants to hold back for 1.1. There is also the Windows stuff, which looks like we should wait for, before cutting 1.0. Since the lists are so short, I decided I don't feel the need to start a thread for them. Chris
