Laden...

Irritierendes Process-Threading Problem

Erstellt von Xynratron vor 9 Jahren Letzter Beitrag vor 9 Jahren 1.945 Views
X
Xynratron Themenstarter:in
1.177 Beiträge seit 2006
vor 9 Jahren
Irritierendes Process-Threading Problem

Hallo zusammen,

hab mich hier lange nicht gemeldet, aber jetzt ein Problem, dass ich logisch nicht erklären kann:

Der Code ist ~4 Jahre alt und benutzt ein Dictionary für ein internes Caching.


private static Dictionary<int, Tuple<DateTime, object>> myDict = new ..

void foo(key int)
{
  if (myDict .ContainsKey(key))
  {
    var result = myDict[key];
    if ((DateTime.Now - result.Item1) > TimeSpan.FromMinutes(5)) //5 Minutes Cache
      {
        myDict.Remove(key);
      }
      else
      {
        return result.Item2;
      }
    }
  [..] load from DB

  if (myDict .ContainsKey(key))
    myDict[key] = new Tuple<DateTime,object>(DateTime.Now, data);
  else
     myDict.Add(key, new Tuple<DateTime, object>(DateTime.Now, data));
  return data;
}


Code ist gekürzt und anonymisiert.

Das ganze ist nicht durch ein lock geschützt, noch wird z.B. ein ConcurrentDictionary verwendet. Wie gesagt, alter, funktionierender Code.

Meine Frage ist also - außer dass das jetzt etwas korrigiert wird - was sorgt dafür, dass das ganze nicht nur manchmal wegen einem threading Problem (in der Routine) auf die Schnauze fällt, sondern mehrere Stunden eine IndexOutOfRangeException beim Insert (Add) in das Dictionary erzeugt?

Threading-Problem hat das ganze sicher. Ein static überlebt keinen Prozesswechsel (AppPool Recycle)

Ich steh gerade auf dem Schlauch...

😃

Xynratron

Herr, schmeiss Hirn vom Himmel - Autsch!

Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.

X
Xynratron Themenstarter:in
1.177 Beiträge seit 2006
vor 9 Jahren

Hmm, schreiben hilft manchmal:

"Code ist gekürzt und anonymisiert."

Regel 1: keinen Code aus "nettigkeit" wegkürzen, nur weil man denkt, da gibt's keinen Fehler.

"load from DB"

Wenn die DB jetzt in einen Lock fährt - aus welchen Gründen auch immer - ist das Verhalten des Codes außenrum nicht mehr definiert. Wir hatten genau das gleichzeitig auf der DB. Also hat der Code zwar macken, war aber nicht schuld.

Ich hoffe das dient wenigstens als gutes Beispiel für schlechtes Fragen nach Hilfe bei einem Fehler...

😃

Alchemy

Herr, schmeiss Hirn vom Himmel - Autsch!

Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.

16.806 Beiträge seit 2008
vor 9 Jahren

Threading-Problem hat das ganze sicher. Ein static überlebt keinen Prozesswechsel (AppPool Recycle)

Recycling ist eigentlich dazu gedacht gewesen, dass problematische Webanwendungen automatisch neu gestartet werden, wenn diese zB Speicher ansammeln.
Gute Webanwendungen brauchen kein Recycle. 😉

W
872 Beiträge seit 2005
vor 9 Jahren

Mittlerweile kann man sich ja den Quellcode der Dictionary Klasse anschauen.
Wenn Du den Code anschaust, siehst Du, daß das bei parallelem/unsynchronisiertem Add das halt vorkommen kann...