Versenden von E-Mails in separaten threads mit QueueUserWorkItem

Ich habe eine Konsole-Anwendung, die sendet maßgeschneiderten E-Mails (mit Anlagen) an verschiedene Empfänger und ich möchte Ihnen gleichzeitig. Ich brauche die Erstellung von separaten SmtpClients um dies zu erreichen, so bin ich mit QueueUserWorkItem zu erstellen, die E-Mails und senden Sie Sie in separate threads.

Snippet

var events = new Dictionary<Guid, AutoResetEvent>();
foreach (...)
{
    ThreadPool.QueueUserWorkItem(delegate
    {
        var id = Guid.NewGuid();
        events.Add(id, new AutoResetEvent(false));
        var alert = //create custom class which internally creates SmtpClient & Mail Message
        alert.Send();
        events[id].Set();
    });   
}
//wait for all emails to signal
WaitHandle.WaitAll(events.Values.ToArray());

Habe ich bemerkt (nur zeitweise), dass manchmal nicht alle emails kommen in die bestimmte Postfächer mit dem obigen code. Ich hätte gedacht, dass mit Send über SendAsync würde bedeuten, die E-Mail wurde geschickt von der Anwendung. Doch indem Sie die folgende Zeile des Codes nach der WaitHandle.WaitAll Linie:

System.Threading.Thread.Sleep(5000);

Scheint zu funktionieren. Mein denken ist, aus welchem Grund auch immer, einige E-Mails noch nicht gesendet wurde (auch nach der Send Methode ausgeführt wurde). Geben Sie die zusätzlichen 5 Sekunden zu geben scheint die Anwendung genug Zeit, um fertig zu stellen.

Ist dies vielleicht ein Problem mit der Art und Weise, warte ich auf die E-Mails zu senden? Oder ist das ein Problem mit dem eigentlichen "Send" - Methode? Hat die E-Mail definitiv versendet wurden, von der app einmal passieren wir diese Linie?

Irgendwelche Gedanken die Idee zu diesem wäre toll, kann nicht ganz scheinen, um meine finger auf die eigentliche Ursache.

Update

Verlangt wie hier ist der SMTP-code:

SmtpClient client = new SmtpClient("Host");
FieldInfo transport = client.GetType().GetField("transport", BindingFlags.NonPublic | BindingFlags.Instance);
FieldInfo authModules = transport.GetValue(client).GetType()
    .GetField("authenticationModules", BindingFlags.NonPublic | BindingFlags.Instance);
Array modulesArray = authModules.GetValue(transport.GetValue(client)) as Array;
modulesArray.SetValue(modulesArray.GetValue(2), 0);
modulesArray.SetValue(modulesArray.GetValue(2), 1);
modulesArray.SetValue(modulesArray.GetValue(2), 3);
try
{
    //create mail message
    ...
    emailClient.Send(emailAlert);
}
catch (Exception ex)
{
    //log exception
}
finally
{
    emailAlert.Dispose();
}

Können Sie erstellen, die eine kurze, aber komplette, Programm das stellt das problem?
Ich werde versuchen die vorgeschlagenen Lösungen dann posten, wenn noch nichts.
Können Sie Ihre SMTP-code?
Warum kannst du nicht verwenden SendAsync und einfach Prozess der Abschluss-Ereignisse, so dass Sie wissen, ob alle E-Mails die gesendet wurden?
Ich glaube, du verpasst einige der code. Ich sehe keinen Anruf zu senden.
Ich möchte zum senden der Benachrichtigungen so schnell wie möglich und Sie können ausgelöst werden, ziemlich viel 1 nach dem anderen, man darf nur senden, 1 asychronously auf jeden 1 mal, das war meine ursprüngliche Idee.
Sie nicht ernsthaft erwarten, dass ich post meine vollständigen code der Anwendung haben Sie? Sicherlich wird der code geschrieben in meinem Fragen & Antworten ist genug für Sie zu gehen?
Nicht die volle Anwendung, nur senden E-Mail-Prozess, wenn es möglich ist wie diese stackoverflow.com/a/1687178/206730 ich möchte vergleichen, Beispiele, finden, klarer, eleganter code

InformationsquelleAutor James | 2010-01-08

c#multithreading smtp

4

Eines der Dinge, die nervt mich über Ihren code, den Sie aufrufen events.Add innerhalb der thread-Methode. Die Dictionary<TKey, TValue> Klasse ist nicht thread-sicher; dieser code sollte nicht in den thread.

Update: ich denke ChaosPandion geschrieben, eine gute Umsetzung, aber ich würde es noch einfacher, machen Sie es so, kann nichts möglicherweise schief gehen in Sachen thread-Sicherheit:
```
var events = new List<AutoResetEvent>();
foreach (...)
{
    var evt = new AutoResetEvent();
    events.Add(evt);
    var alert = CreateAlert(...);
    ThreadPool.QueueUserWorkItem(delegate
    {           
        alert.Send();
        evt.Set();
    });
}
//wait for all emails to signal
WaitHandle.WaitAll(events.ToArray());
```
Habe ich beseitigt, das Wörterbuch komplett hier, und alle AutoResetEvent Instanzen erstellt werden, in dem gleichen thread, später führt eine WaitAll. Wenn dieser code nicht funktioniert, dann muss es ein problem mit der e-mail selbst; entweder ist der server ablegen von Nachrichten (wie viele sind Sie das senden?) oder Sie versuchen zu teilen, etwas, was nicht thread-safe ist zwischen Alert Instanzen (evtl ein singleton oder etwas erklärt statisch).
- Aber sicher jeder thread wird signalisiert, ok, ansonsten mein Antrag würde für immer warten?
- Nicht, wenn die WaitAll geschieht, bevor alle threads haben, hatte sogar eine chance zu geben, Ihre Veranstaltung zu dem Wörterbuch. Das ist, warum es wichtig ist, initialisieren Sie die Liste in dem selben thread, dass Sie warten.
- Ah sehr guter Punkt! Ich denke, dass wird möglicherweise trifft den Nagel auf den Kopf wenn.
- Haben Sie versucht, die aktualisierte version? Ich habe das Gefühl, dass das Wörterbuch zugreifen kann bereits ein Teil des Problems, es ist nicht thread-safe. Konstruieren Sie die Liste der events in den Vordergrund-thread, tun, Weg mit dem Wörterbuch komplett, und Sie sollten in Ordnung sein.
- Nein, nie realisiert, Sie hatten aktualisiert, ich werde give it a shot.
- Spot on, das schien, das Problem zu lösen. Vielen Dank für Ihre Zeit.
- Eine geniale Verschlüsse, eine Sache, die Sie tun können, ist zu verkürzen delegate zu o =>.
InformationsquelleAutor Aaronaught
2

Werden Sie wahrscheinlich wollen, dies zu tun...
```
var events = new Dictionary<Guid, AutoResetEvent>();
foreach (...)
{
    var id = Guid.NewGuid();
    events.Add(id, new AutoResetEvent(false));
    ThreadPool.QueueUserWorkItem((state) =>
    {           
        //Send Email
        events[(Guid)state].Set();
    }, id);   
}
//wait for all emails to signal
WaitHandle.WaitAll(events.Values.ToArray());
```
- oder ThreadPool.QueueUserWorkItem((state) =>{ events[(Guid)state].Set();}, id);
- Ich Tat dies, damit ich nicht zu Fragen, ob er hat .NET 3.5.
- Für das Protokoll ich habe 3.5, nur versuchen, Ihre Lösung am mo wieder zurück zu Euch!
- Hmm, die var sollte eine rote fahne für mich. Ich brauche einen Urlaub.
- Gleichen Ergebnis, 1 E-Mail in dieser Zeit nicht ankommen in der mailbox (ich wartete ein wenig extra für ihn) und füge dann den thread schlafen geklappt!
- Break it down für mich Worked oder Didn't Work.
- Eigentlich ist deine version wohl etwas besser als meine, aber wenn Sie gehen, um pass die id als Staat, warum nicht passieren die AutoResetEvent statt? Das würde zu beseitigen, die möglicherweise nicht Thread-sichere Wörterbuch nachschlagen. Oder noch besser, don ' T-pass-Zustand; speichern der AutoResetEvent in eine lokale variable, bevor Sie es dem Wörterbuch, und legen Sie einfach event.Set() im delegieren. Je mehr ich schaue, desto mehr der Wörterbuch scheint unnötig, man könnte dies genauso gut mit einem List.
- Da das Aussehen nur gelesen, können wir davon ausgehen, es ist thread-sicher. Ich denke, das problem ist, dass das Programm endet zu schnell und killt die senden von E-Mails.
- das ist das Problem, ich bin versucht, um dies zu verhindern!
InformationsquelleAutor ChaosPandion
2

Der Grund, warum es nicht funktioniert ist, dass wenn er trifft Veranstaltungen.Werte.ToArray() nicht alle Delegierten in der Warteschlange ausgeführt haben und daher nicht alle AutoResetEvent-Instanzen wurden Hinzugefügt, um das Wörterbuch.

Beim Aufruf ToArray() die Werte, auf die Eigenschaft abrufen, erhalten Sie nur diejenigen Instanzen, die bereits Hinzugefügt!

Bedeutet dies, werden Sie warten, nur ein paar E-Mails gesendet werden, synchron, bevor der thread blockiert wird fortgesetzt. Der rest der E-Mails, die noch verarbeitet werden, indem die ThreadPool-threads.

Gibt es einen besseren Weg, aber ~~dies ist ein hack~~ erscheint es sinnlos, etwas zu tun, asynchron, wenn Sie möchten, um zu blockieren den aufrufenden thread am Ende...
```
var doneLol = new AutoResetEvent();

ThreadPool.QueueUserWorkItem(
delegate
{
  foreach (...)
  {
    var id = Guid.NewGuid();
    var alert = HurrDurr.CreateAlert(...);
    alert.Send();
  }
  doneLol.Set();
});   

doneLol.WaitOne();
```
Okay, unter Berücksichtigung der folgenden Anforderungen:
1. Console App
2. Viele E-Mails
3. Gesendet werden so schnell wie möglich
Ich würde erstellen Sie die folgende Anwendung:

Laden Sie die E-Mails aus einer text-Datei (Datei.ReadAllLines). Erstellen Sie als Nächstes 2* (Anzahl der CPU-Kerne) Threads. Bestimmen Sie die Anzahl der Zeilen, die verarbeitet werden pro thread; D. H., dividieren Sie die Anzahl der Zeilen (addy pro Zeile) durch die Anzahl der threads, aufgerundet. Als Nächstes legen Sie jeden Faden die Aufgabe, durch seine Liste von Adressen (verwenden Sie Skip(int).Nehmen, (int) aufteilen der Zeilen) und Send()ing jedem E-Mail-synchron. Jeder thread erstellen würde und die eigene SmtpClient. Wie jeder Thread abgeschlossen ist, erhöht ein int in einem freigegebenen Verzeichnis gespeichert. Wenn das int ist gleich der Anzahl der threads, ich kenne alle threads abgeschlossen haben. Der Haupt-Konsole-thread wird ständig prüfen, ob diese Zahl für die Gleichheit und Sleep() für eine bestimmte Länge der Zeit, bevor es die Kontrolle wieder.

Das klingt ein bisschen notdürftigem, aber es funktioniert. Sie können zwicken die Anzahl der threads, um den besten Durchsatz für eine einzelne Maschine, und dann extrapolieren, dass, um zu bestimmen, die richtige Anzahl von threads. Es gibt sicherlich elegantere Wege, die Sperrung der Konsole thread bis zur vollständigen, aber keines so einfach.
- Ich denke, Sie könnten Recht haben. Ich werde es mal ausprobieren.
- Natürlich nutzt nur einen thread für alle die Warnungen... sind Sie immer noch gesendet wird sequentiell statt parallel. Wenn das Ziel ist, nur um es in den hintergrund, dann geht das natürlich in Ordnung, aber wenn er versucht, Sie zu senden alle parallel dann ist dies nicht genau das tun die gleiche Sache.
- Ich weiß, es ist nur zu sinnlos. Warum tun Sie dies asynchron, wenn Sie möchten, um zu blockieren?
- Ich vermutete, dass es war in Ordnung insgesamt zu verbessern Durchsatz. Send() möglicherweise eine relativ lange Zeit zum ausführen, aber wenn der mail-server akzeptiert 10 verbindungen gleichzeitig dann die parallele version wird die Oberfläche sehr viel schneller.
- Ich will die Warnungen gehen so schnell wie möglich und ich will einfach nur die Anwendung zu warten, für ALLE Warnungen gesendet worden. Wenn die Anwendung beendet zu schnell dann einige Benachrichtigungen nicht zugestellt bekommen, also warum muss ich warten.
- Gut, wenn alert.Send() blockiert, bis die gesendet werden (Sie müssen erstellen Sie ein demo-Projekt, um dies zu testen), dann schicken Sie Sie synchron. Wenn Sie verhindern möchten, dass die Anwendung heruntergefahren aus, stoppen Sie aus immer geschickt, einen neuen Thread erstellen und verwenden, um Ihre alerts (d.h., nicht mit einem "hintergrund" - thread, siehe hier: msdn.microsoft.com/en-us/library/h339syd0.aspx )
- ist, was ich Tue, betrachten Sie meine original post. Ich bin das senden der E-Mails in separate threads.
- Genau das ist es. Die Send - Methode ist wahrscheinlich die Blöcke für eine Sekunde oder zwei, aber die meiste Zeit im Leerlauf ist, es ist nur das senden von Daten über den Draht und/oder das warten auf eine Antwort vom mail-server. Senden Sie parallel dazu verbessern den Durchsatz (nehme ich an).
- Ehrlich gesagt, würde ich einfach überspringen die multithreading wie Ihre Anforderungen nicht zu fordern scheinen, dass. Wenn Sie am Ende mit einer Metrik s*tton von E-Mails, die der ThreadPool wird es nicht viel effizienter als laufen Sie synchron (abhängig von # cores und was sonst noch Los ist mit der box).
- Alternativ kann X Anzahl der threads (vielleicht 2x CPU-Kerne) und der Aufteilung der E-Mails unter Ihnen. Ich würde wahrscheinlich tun dies mit einer ConcurrentQueue<T> halten der Handlungen, die jeder thread führt dann...
- im moment gibt es nicht wirklich viele E-Mails gehen jedoch in die Zukunft, die ich erwarte schon eine ganze Menge. Ich werde auf jeden Fall schauen Sie in die ConcurrentQueue<T> Lösung Dank.
- Das ist ein 4.0 Sammlung, btw.
- Ah ich bin am 3.5, ist es etwas, was ich ansehen konnte, in dieser version?
- Hmmm... Es entstand in der Parallel Fx library, aber das hatte nie eine go-live-Lizenz. Vielleicht möchten Sie sich bei Jeffrey Richter (D. H., Wintellect) Power-Threading-Bibliothek. Ich glaube, es hat einige concurrent collections.
InformationsquelleAutor
0

Ich hatte ein ähnliches problem (mit SmtpClient aus einem thread und die E-Mails kommen nur sporadisch).

Zunächst die Klasse, die sendet E-Mails erstellt eine einzelne Instanz der SmtpClient. Das problem wurde gelöst, indem der code zum erstellen einer neuen Instanz der SmtpClient jedesmal, wenn eine E-Mail geschickt werden muss und Entsorgung der SmtpClient (mit einer using-Anweisung).
```
 SmtpClient smtpClient = InitSMTPClient();
 using (smtpClient)
 {
    MailMessage mail = new MailMessage();
    ...
    smtpClient.Send(mail);
 }
```
InformationsquelleAutor robor78

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.