> avoiding port zero,
> and providing the daemon binary with a dynamic configuration,
> so the port is chosen before-hand by the test "client".
http://p3rl.org/Net::EmptyPort does that.
pgpzGKb2OVY2w.pgp
Description: Digitale Signatur von OpenPGP
On Sat, Apr 25, 2015 at 09:19:00PM +0200, Cosimo Streppone wrote:
> Il 24/04/2015 18:12, Michael Kiwala ha scritto:
> >Why not use lsof to query the port that was assigned?
> I'm often a bit reluctant to use system commands as that
> makes the whole process more OS dependent.
> Even considering Win
Il 24/04/2015 18:12, Michael Kiwala ha scritto:
On Thu, Apr 23, 2015 at 2:53 PM, Tim Bunce mailto:tim.bu...@pobox.com>> wrote:
That approach only applies to your perl statsd, right? For the nodejs
or C statsd's you don't have an easy[*] a way to find the port.
I was about to suggest ru
On Thu, Apr 23, 2015 at 2:53 PM, Tim Bunce wrote:
> On Thu, Apr 23, 2015 at 08:21:28PM +0200, Cosimo Streppone wrote:
> > On 23. april 2015 19:02, Tim Bunce wrote:
> >
> > > On Thu, Apr 23, 2015 at 05:59:34PM +0200, Cosimo Streppone wrote:
> > >>
> > >> When the fork + exec'd daemon chooses a ran
Il 23/04/2015 21:53, Tim Bunce ha scritto:
How is "the port number is saved into the file" when you don't know
which port it has bound itself to?
The daemon starts and binds using port 0. Still within the daemon code,
I can then query for the used port, through regular socket calls.
After that
On Thu, Apr 23, 2015 at 08:21:28PM +0200, Cosimo Streppone wrote:
> On 23. april 2015 19:02, Tim Bunce wrote:
>
> > On Thu, Apr 23, 2015 at 05:59:34PM +0200, Cosimo Streppone wrote:
> >>
> >> When the fork + exec'd daemon chooses a random port, I need to be able
> >> to know which port it has boun
On 23. april 2015 20:23, Chad Granum wrote:
> Can you start the server and get the port in the parent process, then
> fork and run the tests from the child?
Unfortunately that is not possible, as client and server code
are completely separated, and I'd like to run
the test suite against the javas
oops ignore my last message, obviously forking the server is a dumb idea.
On Thu, Apr 23, 2015 at 11:23 AM, Chad Granum wrote:
> Can you start the server and get the port in the parent process, then fork
> and run the tests from the child?
>
> On Thu, Apr 23, 2015 at 11:21 AM, Cosimo Streppone
Can you start the server and get the port in the parent process, then fork
and run the tests from the child?
On Thu, Apr 23, 2015 at 11:21 AM, Cosimo Streppone wrote:
> On 23. april 2015 19:02, Tim Bunce wrote:
>
> > On Thu, Apr 23, 2015 at 05:59:34PM +0200, Cosimo Streppone wrote:
> >>
> >> Whe
On 23. april 2015 19:02, Tim Bunce wrote:
> On Thu, Apr 23, 2015 at 05:59:34PM +0200, Cosimo Streppone wrote:
>>
>> When the fork + exec'd daemon chooses a random port, I need to be able
>> to know which port it has bound itself to, and here lies the problem.
>
> Perhaps dodge the problem by not p
On Thu, Apr 23, 2015 at 05:59:34PM +0200, Cosimo Streppone wrote:
>
> Now, problem.
>
> I'd like to use port 0 to bring up the daemon, so that the test suite
> can be run in parallel without port clashes. With port == 0 the TCP/UDP
> bind will happen on a random free port.
>
> When the fork + ex
Hi,
trying to pick your brains here.
I hope to be able to explain decently what I'm trying to achieve.
This is about the test suite of Net::Statsd::Server, a perl port
of the javascript statsd daemon, and in particular the
t/integration-tests/*.t cases.
Integration here means that the *.t files,
12 matches
Mail list logo
