Why does the Email trace listener prevent other listeners from working?

Question

We use Enterprise Library Application Block 6 to implement logging. We have two trace listeners, one for logging to the database, another for sending email-alerts. They are configured like this:

<loggingConfiguration name="Logging Application Block" tracingEnabled="true" defaultCategory="MyProject" logWarningsWhenNoCategoriesMatch="true">
    <listeners>
        <add name="Database Trace Listener" type="Microsoft.Practices.EnterpriseLibrary.Logging.Database.FormattedDatabaseTraceListener,Microsoft.Practices.EnterpriseLibrary.Logging.Database" ... />
        <add name="Email Trace Listener" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.EmailTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" ... />
    </listeners>
    <categorySources>
        <add switchValue="All" name="MyProject">
            <listeners>
                <add name="Email Trace Listener" />
                <add name="Database Trace Listener" />
            </listeners>
        </add>
    </categorySources>
    ...
</loggingConfiguration>

Our problem is, that if the Email trace listener does't work for some reason - the SMTP server is down, for instance - then the Database Trace Listener doesn't work either.
Is there a way to configure the DB Trace Listener to work even if the Email tracing failed?

Answer 1

It seems I managed to solved it, I had to reverse the order of the listeners like this:

            <listeners>
                <add name="Database Trace Listener" />
                <add name="Email Trace Listener" />
            </listeners>

And now not only the logging works, but I even get another error message in the log about the Email trace failing:

"Tracing to LogSource 'MyProject' failed. Processing for other sources will continue. See summary information below for more information. Should this problem persist, stop the service and check the configuration file(s) for possible error(s) in the configuration of the categories and sinks."

I can see some rationale in this behaviour, however I still don't understand why at least the DB listener didn't work in the first case.