В качестве дополнительной опции вы можете захватить потоки и просто закрыть их. Не самая лучшая идея в мире, и я все равно, но она работает в крайнем случае.
ускаю 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, а не давать мне правильные значения.
Есть идеи? Едва ли это соглашение, но определенно было бы приятно иметь.