Mein Prozess hat auf einmal hundertausende Handles

[yogie]

Hallo,
mal ganz naiv ... steht das Problem ev. in Zusammenhang mit der 24 Stunden Angabe?
Oder ist die Aussage ... alles läuft 23 h 59 min problemlos ... mehr symbolisch zu verstehen.
Ich denke da an solche Sachen, wie Zeitumrechnung über einen 24 Std. Zeitraum hinweg und
dann entsprechende Überläufe und die vielen Handles sind dann nur ein Folgeproblemm.

[Der schöne Günther]

Gute Frage, aber das war wirklich nur rein symbolisch zu verstehen. Im ersten Fall weiß ich nicht wie lange es lief, im zweiten Fall waren es so um die 22 Stunden.

[TiGü]

Ach, wer hat nicht so Quelltextzeilen:

Delphi-Quellcode:

if Now > zufälligerWert then
  RasteKomplettAusUndBringeDasSystemZumAbsturz;

Die heißen natürlich in der Realität SendDocToNetworkPrinter, LoadDataFromDatabase, SaveApplicationSetting usw. usf.! :-D

[Der schöne Günther]

Erst einmal vielen Dank noch einmal für die Antworten.

So wie es mittlerweile aussieht ist nach dem Zurückstellen auf den von uns gelieferten Drucker das Wochenende über nichts mehr vorgefallen, alles lief bestens.

Naja, dafür loggt die Anwendung in der nächsten Version auch fleißig Dinge mit wie Handle-Anzahl, CPU/Speicher-Auslastung, Anzahl der IO-Vorgänge auf der Platte...

Hatte also auch sein Gutes 8-)

[TiGü]

Also lag es letztendlich an einen fehlerhaften Drucker(-treiber)?
Spannend und nur nice-to-have wäre natürlich, den fehlerhaften Drucker vom Kunden (leihweise) zu bekommen und in der Entwicklung testen zu können.
Eventuell kann man derartige Fehler-Szenarien auch im eignen Programmcode behandeln.
Aber das wäre auch nur was für ruhige Stunden.

[nahpets]

Zitat:

Zitat von TiGü (Beitrag 1379331)

Also lag es letztendlich an einen fehlerhaften Drucker(-treiber)?
Spannend und nur nice-to-have wäre natürlich, den fehlerhaften Drucker vom Kunden (leihweise) zu bekommen und in der Entwicklung testen zu können.
Eventuell kann man derartige Fehler-Szenarien auch im eignen Programmcode behandeln.
Aber das wäre auch nur was für ruhige Stunden.

Reicht es da nicht aus, nur den entsprechenden Treiber zu installieren?
Der Drucker selbst muss ja nicht angeschlossen sein. Den Treiber auswählen und die Druckaufträge im Spooler stehen lassen. Kann man dann dort ja später rausschmeißen.

Die grundsätzliche Funktion von Druckaufträgen hab' ich immer erstmal mit ausgeschaltetem Drucker entwickelt und getestet bzw. den Drucker am Entwicklungsrechner offline geschaltet.

Ein eventuell vorhandenes Fehlverhalten des Druckertreibers müsste aber eigentlich trotzdem auffallen.

[TiGü]

Zitat:

Zitat von nahpets (Beitrag 1379351)

Reicht es da nicht aus, nur den entsprechenden Treiber zu installieren?
Der Drucker selbst muss ja nicht angeschlossen sein. Den Treiber auswählen und die Druckaufträge im Spooler stehen lassen. Kann man dann dort ja später rausschmeißen.

Die grundsätzliche Funktion von Druckaufträgen hab' ich immer erstmal mit ausgeschaltetem Drucker entwickelt und getestet bzw. den Drucker am Entwicklungsrechner offline geschaltet.

Ein eventuell vorhandenes Fehlverhalten des Druckertreibers müsste aber eigentlich trotzdem auffallen.

Stimmt auch wieder.
Das wäre Schritt eins.
Wenn sich das Fehlverhalten damit aber nicht reproduzieren lässt, kommt man um eine vollständige Testkette nicht drum rum.

[mkinzler]

Zitat:

Ein eventuell vorhandenes Fehlverhalten des Druckertreibers müsste aber eigentlich trotzdem auffallen.

Nicht unbedingt, wenn das Fehlverhalten bei der Kommunikation mit dem Drucker entsteht

[Luckie]

Deutet das aber dann nicht auch auf eine unvollständige Fehlerbehandlung im Code hin?

[nahpets]

Um welchen Fehler handelt es sich in meinem Programm, wenn ein Druckertreiber Handles nicht freigibt?

Welche Chance der Fehlerbehebung habe ich denn dann?

Allenfalls kann ich doch nur das Problem feststellen und ggfls. warnen ... aber die Chance der Fehlerbehebung im eigenen Programm dürfte da doch eher gegen 0 tendieren. Oder irre ich da?