none
System.Threading.ThreadAbortException bei Fehler: .NET Framework execution was aborted by escalation policy because of out of memory. RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    wie kann ich die System.Threading.ThreadAbortException behandeln, wenn die Fehlermeldung im Ereignis-Protokoll ".NET Framework execution was aborted by escalation policy because of out of memory" lautet.

    Ich arbeite mit Microsoft SQL-Server 2005 und der Microsoft .NET Framwork Version 2.0.50727 SP2 - Version dazu und erstelle die Stored Procedures über die Common Language Runtime.

    In der Dokumentation steht, dass man im Catch-Block zur Try-Anweisung eben die System.Threading.ThreadAbortException abfangen soll und darin dann die Fehlerbehandlung macht, bzw. dass zuerst noch das Finally abgearbeitet wird und dann die Exception nochmals ausgelöst wird.

    Bei mir im Debug-Mode komme ich zwar in der Exception an, danach geht aber gar nichts mehr. Was ja eigentlich auch logisch ist, da kein Memory mehr da ist.

    Wie kann man solch eine Ausnahme handhaben? Eigentlich muss der Thread ja abbrechen, damit der Speicher wieder zur Verfügung steht, aber wenn ich keinen Speicher mehr habe, wie kann man dann noch reagieren.

    Oder kann man noch Informationen in einen anderen Thread übernehmen, und den Vorgang so irgendwie ordentlich abschließen?

    Danke für jede Info

    Carla

     

     

     

    Software-Developer
    Montag, 26. Juli 2010 12:43
    |

Antworten

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    Hallo Carla,

    wenn die ThreadAbortException aufgrund von Speichermangel ausgelöst wurde,
    wie der Thread-Titel vermuten läßt, so läßt sich nicht mehr viel abfangen.
    Dann geht der SQL Server davon aus, dass die Datenintegrität nicht mehr gewährleistet ist,
    und bricht die Ausführung ab, was in der Regel ein entladen der AppDomain zur Folge hat.

    Eine Möglichkeit wäre der SQL CLR über MemToLeave mehr Speicher zu verschaffen:
    http://blogs.msdn.com/b/sqlclr/archive/2006/03/24/560154.aspx

    und auch  Various memory errors are logged to SQL Server error log when using SQL CLR objects

    Ansonsten hilft nur, den Verursacher des zu großen Speicherverbrauchs zu ermitteln,
    was je nach ausgeführter Aufgabe, mehr oder weniger schwierig ist...

    Gruß Elmar

     

    • Als Antwort markiert CarlaKoehler Dienstag, 27. Juli 2010 08:21
    Montag, 26. Juli 2010 16:05
    |
  • Question
    Anmelden
    0
    Anmelden

    Vielen Dank Elmar, für die Antwort.

    Das habe ich leider so befürchtet.

    Wir haben dem Thema schon mehr Speicher gegeben, aber  bei 1% von den Fällen, reicht der halt mit dieser sehr komfortablen und schnellen Methodik, die ich hier über die CLR anwende nicht aus.

    Im Moment lese ich die Daten aus einem zusammengebastelten Dataset aus Tabellen in einen String aus und bei dem klemmts halt dann, wenn ich den wiederum als xml-Typ in die Datenbank schreiben will.

    Schreiben als varbinary funktioniert zwar im Moment über einen Memory-Stream auch für die Großen Datenmengen - da stellt sich aber die Frage wie lange, da das auch über das Memory geht.... und ob es sich dann lohnt, dass die weiterverarbeitende Firma das umstellt.

    Mit direkten SELECT ..... FOR xml Auto, ELEMENTS, TYPE - habe ich Probleme mit der TYPE-Umwandlung aus den Tabellen, das funktioniert nicht für alle Tabellen, die ich brauche - warum auch immer...

    Schreiben ins File-System ist eigentlich keine Alternative....

    und dann bin ich mit meinem Latein am Ende.

     

    Carla

    Software-Developer
    Dienstag, 27. Juli 2010 08:21
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Carla,

    DataSets sind relativ speicherintensiv, da können spezielle Typen helfen,
    was allerdings zusätzlichen (teilweise erheblichen) Aufwand bedeutet.

    Die FOR XML Methoden benötigen mit Sicherheit weiteren kostbaren Speicher.
    Und wenn man dort nicht sehr aufpasst, kommt es dort schnell zu Konvertierungen
    (und wieder Speicherverbrauch). So kann es sinnvoller sein, sein XML selbst zu basteln.

    Leider steht für SQL Server 2005 noch kein XDocument (ab .NET 3.5) zur Verfügung,
    was günstiger ist als XmlDocument.

    Anstatt einer CLR Prozedur solltest Du überlegen, ob es nicht ein externes
    .NET Programm sein kann. Damit fallen einige Speicherrestriktionen,
    da es damit ein zusätzlicher Prozess (und eigener Adressraum) ist.
    Eine Umstellung von CLR Prozeduren sollte dort relativ einfach sein,
    da man vieles vom Code direkt übernehmen kann.

    Gruß Elmar

    Dienstag, 27. Juli 2010 09:58
    |