Thanks for the feedback Philip,
I did some extensive debugging and found it to indeed be a bug with our
AV software... Apparently, the way it is using the Sophos SAVI libraries
under load has highlighted an issue with threading in our AV software.
The issue was related to Exim opening multiple connections to the AV
daemon which was then bombing out since the Sophos implementation wasn't
thread safe. This was proven by using serialize_hosts directive in Exim
which never caused an issue (since it only opens a since connection).
We have raised it with our AV vendor who have now acknowledged the bug
and are looking at a fix for us.
I'd just like to take this opportunity to say how happy we are with Exim
and how great the community support is... Keep up the good work guys!
Cheers,
Ray
--
Philip Hazel wrote:
> On Thu, 15 May 2003, Ray Jackson wrote:
>
>
>>However, when we started load testing we ran into trouble. Basically,
>>we discovered that our AV daemon would do 2 things:
>>
>> o It would take up to 2 seconds to establish/close an SMTP session
>> o It would automatically disconnect an SMTP session as soon as it saw
>> an end-of-message. (i.e. it see's the '.' line and with a second or
>> so disconnects the session)
>
>
> That second behaviour is not compliant with the SMTP protocol. See RFC
> 2821.
>
>
>>The AV daemon will allow up to 'x' concurrent connections (we set it at
>>100) - however it appears that it will close an active connection after
>>receiving just one email message).
>
>
> That is also not compliant with the SMTP protocol.
>
>
>>... R=av_router T=av_transport defer (-18): Remote host 192.168.1.17
>>[192.168.1.17] closed connection in response to end of data
>
>
> That's Exim saying "this connection died unexpectedly".
>
>
>>... unexpected disconnection while reading SMTP command from mailserv
>>[127.0.0.1]
>
>
> That's something completely different - a problem with an *incoming*
> connection on the local interface.
>
>
>>... 192.168.1.17 [192.168.1.17]: Connection refused
>>... R=av_router T=av_transport defer (111): Connection refused
>
>
> That's your AV host refusing to accept a connection.
>
>
>>It appears that Exim was trying to send subsequent messages down the
>>same connection and was booted out my the AV daemon?
>
>
> I don't think so. It certainly looks at first sight as though the AV
> daemon is just plain broken.
>
>
>>What I want Exim to do (I think) is open a completely new socket
>>connection with our AV daemon each time a message is sent to the
>>av_transport (i.e. a completely new process) - as it appears that the AV
>>daemon is tearing down the socket connection as soon as it has received
>>one complete message.
>
>
> No, it looks like it is tearing down the connection *before* it has
> completely received one message, because it hasn't sent an
> acknowledgement.
>
> Is there a way of doing this using the SMTP
>
>>transport or do I have to go down the 'pipe' route? I though
>>connection_max_messages would help me - but this appears not to be the case.
>
>
> connection_max_messages will do what you ask, but as I say above, I
> don't think that is the problem.
>
> --
> Philip Hazel University of Cambridge Computing Service,
> ph10@??? Cambridge, England. Phone: +44 1223 334714.
>
>
> --
>
> ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##
>
