В качестве дополнительной опции вы можете захватить потоки и просто закрыть их. Не самая лучшая идея в мире, и я все равно, но она работает в крайнем случае.

ускаю wkhtmltopdf из моего Java-приложения (часть сервера Tomcat, работающего в режиме отладки в Eclipse Helios на 64-битной Win7): я хотел бы дождаться его завершения, затем Do More Stuff.

String cmd[] = {"wkhtmltopdf", htmlPathIn, pdfPathOut};
Process proc = Runtime.getRuntime().exec( cmd, null );

proc.waitFor();

НоwaitFor() никогда не вернется. Я все еще вижу процесс в диспетчере задач Windows (с командной строкой, которую я передал exec (): выглядит хорошо). И ЭТО РАБОТАЕТ. wkhtmltopdf создает PDF-файл, который я ожидал, именно там, где я и ожидал. Я могу открыть его, переименовать, что угодно, даже когда процесс еще запущен (до того, как я вручную завершу его).

Из командной строки все нормально:

c:\wrk>wkhtmltopdf C:\Temp\foo.html c:\wrk\foo.pdf
Loading pages (1/6)
Counting pages (2/6)
Resolving links (4/6)
Loading headers and footers (5/6)
Printing pages (6/6)
Done

Процесс выходит просто отлично, и жизнь продолжается.

Так о чем этоruntime.exec() что приводит к тому, что wkhtmltopdf никогда не завершается?

Я мог бы взять proc.getInputStream () и искать «Готово», но это ... мерзко. Я хочу что-то более общее.

Я звоню exec () с рабочим каталогом и без него. Я пробовал с и без пустого массива "env". Нет радости

Почему мой процесс зависает, и что я могу сделать, чтобы это исправить?

PS: я пробовал это с парой других приложений командной строки, и они оба демонстрируют одинаковое поведение.

Дальнейшие неприятности.

Я пытаюсь прочитать стандарт и ошибки без успеха. Из командной строки я знаю, что должно быть что-то удивительно похожее на мой опыт работы с командной строкой, но когда я читаю поток ввода, возвращаемый proc.getInputStream (), я сразу получаю EOL (-1, я используюinputStream.read()).

Я проверил JavaDoc для процесса и нашел это

Родительский процесс использует эти потоки для подачи входных данных и получения выходных данных из подпроцесса. Поскольку некоторые собственные платформы предоставляют ограниченный размер буфера только для стандартных входных и выходных потоков, невозможность оперативной записи входного потока или чтения выходного потока подпроцесса может привести к блокировке подпроцесса [b] и даже к тупиковой блокировке [/ b].

Акцент добавлен. Я попробовал это. Первый read () в Standard Out inputStream блокировался, пока я не убил процесс ...

С WKHTMLTOPDF

С общей командной строкой ap & no params, поэтому она должна «сбросить использование и завершиться», она высасывает соответствующий std :: out, а затем завершается.

Интересно!

Проблема с версией JVM? Я использую 1.6.0_23. Последняя версия ... v24. Я только что проверил журнал изменений и не вижу ничего многообещающего, но все равно попробую обновить.

Хорошо. Не позволяйте входным потокам заполняться, иначе они будут блокироваться. Проверьте..close() может также предотвратить это, но не очень яркий.

Это работает в целом (включая общие приложения командной строки, которые я тестировал).

В конкретных Тем не менее, он падает. Похоже, что wkhtmltopdf использует некоторые манипуляции с терминалом / курсор для создания ASCII-графического индикатора выполнения. Я считаю, что это заставляет inputStream немедленно возвращать EOF, а не давать мне правильные значения.

Есть идеи? Едва ли это соглашение, но определенно было бы приятно иметь.

Ответы на вопрос(4)

Ваш ответ на вопрос