headers
Douglas Hunter | 1 May 2008 21:45
Favicon

async and tls

Howdy,

First, thank you all for such a fantastic piece of software.

I've recently been exploring using async for our production mail servers.

We use the tls plugin, which I understand hasn't been re-written for the 
async server yet.

First I tried the patch here: 
http://www.nntp.perl.org/group/perl.qpsmtpd/2007/10/msg7423.html, but 
then read this message: 
http://www.nntp.perl.org/group/perl.qpsmtpd/2007/10/msg7471.html.

The following patch seems to work for me, but I'm a bit concerned that 
I'm being naive [grin].

Thanks again!

-- Douglas
Attachment (tls-async.patch): text/x-patch, 1473 bytes
Permalink | Reply | 10 comments |
headers
Chris Babcock | 1 May 2008 23:20

Re: async and tls

Douglas Hunter wrote:
> Howdy,
> 
> First, thank you all for such a fantastic piece of software.
> 
> I've recently been exploring using async for our production mail servers.
> 

Why?  Are you having issues with the other modes of operation?

Async (at this point) is best suited to systems with very high 
performance and concurrency requirements.  If your system can run 
without using async, the other modes are simpler to implement and better 
tested.

-Chris
Permalink | Reply | 9 comments |
headers
Matt Sergeant | 1 May 2008 23:31
Favicon

Re: async and tls

On 1-May-08, at 5:20 PM, Chris Babcock wrote:

> Douglas Hunter wrote:
>> Howdy,
>> First, thank you all for such a fantastic piece of software.
>> I've recently been exploring using async for our production mail  
>> servers.
>
> Why?  Are you having issues with the other modes of operation?
>
> Async (at this point) is best suited to systems with very high  
> performance and concurrency requirements.  If your system can run  
> without using async, the other modes are simpler to implement and  
> better tested.

On the other hand I'm happy to have people putting -async to use, as  
that's the best way we'll find bugs. It's very stable for us in  
"production" albeit on a spamtrap rather than serving real mail. And  
there are a few others on this list that appear to be using it in  
production on non-spamtrap environments.

Matt.
Permalink | Reply | 3 comments |
headers
Douglas Hunter | 1 May 2008 23:55
Favicon

Re: async and tls

Chris Babcock wrote:
> Douglas Hunter wrote:
>> Howdy,
>>
>> First, thank you all for such a fantastic piece of software.
>>
>> I've recently been exploring using async for our production mail servers.
>>
> 
> Why?  Are you having issues with the other modes of operation?
> 

Yes, there are too many concurrent connections coming into our mail 
server for the forkserver to handle given the iron it runs on, and we're 
periodically bouncing mail.

> Async (at this point) is best suited to systems with very high 
> performance and concurrency requirements.  If your system can run 
> without using async, the other modes are simpler to implement and better 
> tested.

True, and thanks for the feedback.  Async is also cool! [grin]  (Yes, 
I'm that guy who also runs Apache2 with the experimental event MPM).

I think a modern IO event loop will help me, even if the first thing it 
shows me is that I need to optimize my plugins [grin].

Thanks,

-- Douglas
(Continue reading)

Permalink | Reply | 4 comments |
headers
Fred Moyer | 2 May 2008 00:09

Re: async and tls

Douglas Hunter wrote:
> Chris Babcock wrote:
>> Douglas Hunter wrote:
>>> Howdy,
>>>
>>> First, thank you all for such a fantastic piece of software.
>>>
>>> I've recently been exploring using async for our production mail 
>>> servers.
>>>
>>
>> Why?  Are you having issues with the other modes of operation?
>>
> 
> Yes, there are too many concurrent connections coming into our mail 
> server for the forkserver to handle given the iron it runs on, and we're 
> periodically bouncing mail.

You might want to try the prefork server as an intermediate solution 
before you get async completely dialed in.
Permalink | Reply | 0 comments |
headers
Douglas Hunter | 2 May 2008 04:31
Favicon

Re: async and tls

Matt Sergeant wrote:
> On 1-May-08, at 5:20 PM, Chris Babcock wrote:
> 
>> Async (at this point) is best suited to systems with very high 
>> performance and concurrency requirements.  If your system can run 
>> without using async, the other modes are simpler to implement and 
>> better tested.
> 
> On the other hand I'm happy to have people putting -async to use, as 
> that's the best way we'll find bugs. It's very stable for us in 
> "production" albeit on a spamtrap rather than serving real mail. And 
> there are a few others on this list that appear to be using it in 
> production on non-spamtrap environments.
> 

I should add that all of my tests with async proved it to be quite 
stable for our uses, with the exception of the tls plugin, which we knew 
to need work from following the list traffic.

I only tested STARTTLS from the default port with the patch I supplied, 
but that seemed to work well.  I'm just not confident enough with my 
async-fu to recommend that patch to other folks until it gets some more 
action and community vetting.  But the tls plugin isn't a problem with 
async, it's something we all know needs to be upgraded in order to work 
with async.

Thanks for the async server, and if there is anything other than trying 
to use it live that I can do to help it out, please let me know.

Thanks again,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Chris Lewis | 2 May 2008 05:13
Favicon

Re: async and tls

Douglas Hunter wrote:

> I only tested STARTTLS from the default port with the patch I supplied, 
> but that seemed to work well.  I'm just not confident enough with my 
> async-fu to recommend that patch to other folks until it gets some more 
> action and community vetting.  But the tls plugin isn't a problem with 
> async, it's something we all know needs to be upgraded in order to work 
> with async.

As a FYI, TLS with async is also an issue for us.  I'll be testing your 
patch on a VERY large spamtrap in the next little while.
Permalink | Reply | 1 comment |
headers
Douglas Hunter | 2 May 2008 22:27
Favicon

Re: async and tls

Chris Lewis wrote:
> 
> As a FYI, TLS with async is also an issue for us.  I'll be testing your 
> patch on a VERY large spamtrap in the next little while.

Very cool.  As I understand the code in IO::Socket::SSL::start_SSL, the 
patch I provided forces blocking on the socket being upgraded, which 
could defeat the purpose of the patch if there are slow clients being 
upgraded.

Maybe this is why there were previous statements on this list explaining 
that it might not be too simple to upgrade the connection to SSL using 
async.

I'll continue to dig, and hopefully figure out how to unblock the SSL 
negotiation.

Thanks,

-- Douglas
Permalink | Reply | 0 comments |
headers
Charlie Brady | 3 May 2008 00:20
Picon
Picon

Re: async and tls


On Thu, 1 May 2008, Douglas Hunter wrote:

> Chris Babcock wrote:
>>  Douglas Hunter wrote:
>> >  I've recently been exploring using async for our production mail 
>> >  servers.
>>  Why?  Are you having issues with the other modes of operation?
>> 
>
> Yes, there are too many concurrent connections coming into our mail server 
> for the forkserver to handle given the iron it runs on, and we're 
> periodically bouncing mail.

Having more concurrent connections than your server can confortably be 
able to handle should not result in bouncing mail. Why is mail being 
bounced?
Permalink | Reply | 2 comments |
headers
Douglas Hunter | 3 May 2008 01:56
Favicon

Re: async and tls

Charlie Brady wrote:
> On Thu, 1 May 2008, Douglas Hunter wrote:
>> Yes, there are too many concurrent connections coming into our mail 
>> server for the forkserver to handle given the iron it runs on, and 
>> we're periodically bouncing mail.
> 
> Having more concurrent connections than your server can confortably be 
> able to handle should not result in bouncing mail. Why is mail being 
> bounced?

When connections to our mail server time out, sending MTA retries the 
message.  If subsequent retries of that message time out as many times 
as the sending MTA is configured to retry, the sending MTA bounces the 
message.

-- Douglas
Permalink | Reply | 0 comments |

Gmane