:04
To: bert hubert
Cc: Mike; pdns-users@mailman.powerdns.com
Subject: Re: [Pdns-users] tcp listener issue - hopefully fixed
Bert,
I re-downloaded the src and rebuilt my RPM. It appears to be up and running
now. Unknown why the first compiles had this issue. I have been testing the
last
listener issue - hopefully fixed
Simon,
Brief reply, am on the road. 3.3 will be released the moment you, brad or
laurent confirm the issue is truly gone.
What I can do is make packages that will be binary identical to the real 3.3
once you 'bless' them as having solved your issue. This would
hubert [mailto:bert.hub...@netherlabs.nl]
Sent: Thursday, September 09, 2010 5:06 AM
To: Brad Dameron
Cc: Mike; pdns-users@mailman.powerdns.com
Subject: Re: [Pdns-users] tcp listener issue - hopefully fixed
On Wed, Sep 08, 2010 at 11:16:41PM +, Brad Dameron wrote:
Bert,
I can't seem to get
On Sun, Aug 29, 2010 at 09:17:01PM +, Brad Dameron wrote:
The release process for 3.3 can now start - only 1 feature request left
to
finish.
Good to hear Bert. I'll run it through the ringer on Monday and see if we can
reproduce the problem. Cross fingers that it is fixed.
Brad,
On Mon, Aug 23, 2010 at 11:37:42AM +0100, Simon Bedford wrote:
Just returned from annual leave to this welcome news, has anyone had
a chance to try it as yet and investigate whether the bug still
manifests? And does it no longer happen when running Brad's test
script?
Simon,
Sadly we found
On Sun, Aug 29, 2010 at 04:56:14PM +0200, bert hubert wrote:
We've fixed yet another bug that might be causing the issue, and we are
currently testing that.
This drop can be found on
http://svn.powerdns.com/snapshots/pdns-recursor-3.3-pre.tar.bz2
Our testing shows that the problem
-Original Message-
From: pdns-users-boun...@mailman.powerdns.com [mailto:pdns-users-
boun...@mailman.powerdns.com] On Behalf Of bert hubert
Sent: Sunday, August 29, 2010 11:31 AM
To: Mike
Cc: Brad Dameron; pdns-users@mailman.powerdns.com
Subject: Re: [Pdns-users] tcp listener issue
Hi everybody,
After an *exhaustive* search, no definitive cause of the TCP/IP issue has
been found, even though we were eventually able to reproduce it (with the
help of Brad).
To make headway in solving this, we've now removed most of the old TCP/IP
connection accounting code, and replaced it
