Auf die Frage: Wie prüft man das Vorhandensein eines Prozesses via PID
Ein ganz simpler Aufruf wie
sun.management.ManagementFactory.getRuntimeMXBean().getName()
liefert uns die <pid>@<rechnername>. Z.B 5536@mo. Die Java Klasse kann diese Information in die lock Datei schreiben.
Das geht leider nur ab java version 1.5.
Statt getPids() würde ich gerne die Kommandoaufruf tasklist.exe verwenden. Dieser Kommandobefehl liefert folgende Information:
- Abbildname
- PID
- Sitzungsname
- Sitz.-Nr.
- Speichernutzung
Parallele SOSFTP-Instanzen, die auch in die Historiendatei schreiben wollen, überprüfen zuerst, ob eine lock Datei existiert. Wenn ja, wird das Schreiben verzögert. Nach der Verzögerung wird wieder überprüft, ob die lock Datei weiterhin existiert. Wenn nicht, kann der parallele SOSFTP-Instanz wie gewohnt schreiben. Wenn der lock Datei weiterhin existiert, dann wird der PID aus der lock Datei gelesen und mithilfe von tasklist überprüft, ob diese Process mit der PID weiter existiert. Ist der Prozess nicht mehr vorhanden, dann löscht SOSFTP die lock Datei und legt sie neu an mit seiner PID.
ZUR INFO: Der Kommandobefehl tasklist wird meistens mit Windows mitgeliefert. Wenn nicht, dann kann Sie kostenfrei heruntergeladen werden und unter c:/Windows/System32 gespeichert werden.
Es gibt auch die nette Kommandozeile mit taskkill.exe, der wie der Name sagt, einen process killen kann.
Wäre es ein Problem auf java 1.5 umzusteigen.
New Feature
Closed
Major
Auf die Frage: Wie prüft man das Vorhandensein eines Prozesses via PID
Ein ganz simpler Aufruf wie
sun.management.ManagementFactory.getRuntimeMXBean().getName()
liefert uns die <pid>@<rechnername>. Z.B 5536@mo. Die Java Klasse kann diese Information in die lock Datei schreiben.
Das geht leider nur ab java version 1.5.
Statt getPids() würde ich gerne die Kommandoaufruf tasklist.exe verwenden. Dieser Kommandobefehl liefert folgende Information:
Parallele SOSFTP-Instanzen, die auch in die Historiendatei schreiben wollen, überprüfen zuerst, ob eine lock Datei existiert. Wenn ja, wird das Schreiben verzögert. Nach der Verzögerung wird wieder überprüft, ob die lock Datei weiterhin existiert. Wenn nicht, kann der parallele SOSFTP-Instanz wie gewohnt schreiben. Wenn der lock Datei weiterhin existiert, dann wird der PID aus der lock Datei gelesen und mithilfe von tasklist überprüft, ob diese Process mit der PID weiter existiert. Ist der Prozess nicht mehr vorhanden, dann löscht SOSFTP die lock Datei und legt sie neu an mit seiner PID.
ZUR INFO: Der Kommandobefehl tasklist wird meistens mit Windows mitgeliefert. Wenn nicht, dann kann Sie kostenfrei heruntergeladen werden und unter c:/Windows/System32 gespeichert werden.
Es gibt auch die nette Kommandozeile mit taskkill.exe, der wie der Name sagt, einen process killen kann.
Wäre es ein Problem auf java 1.5 umzusteigen.
- Abbildname
- PID
- Sitzungsname
- Sitz.-Nr.
- Speichernutzung
Parallele SOSFTP-Instanzen, die auch in die Historiendatei schreiben wollen, überprüfen zuerst, ob eine lock Datei existiert. Wenn ja, wird das Schreiben verzögert. Nach der Verzögerung wird wieder überprüft, ob die lock Datei weiterhin existiert. Wenn nicht, kann der parallele SOSFTP-Instanz wie gewohnt schreiben. Wenn der lock Datei weiterhin existiert, dann wird der PID aus der lock Datei gelesen und mithilfe von tasklist überprüft, ob diese Process mit der PID weiter existiert. Ist der Prozess nicht mehr vorhanden, dann löscht SOSFTP die lock Datei und legt sie neu an mit seiner PID. ZUR INFO: Der Kommandobefehl tasklist wird meistens mit Windows mitgeliefert. Wenn nicht, dann kann Sie kostenfrei heruntergeladen werden und unter c:/Windows/System32 gespeichert werden. Es gibt auch die nette Kommandozeile mit taskkill.exe, der wie der Name sagt, einen process killen kann. Wäre es ein Problem auf java 1.5 umzusteigen.