Многопоточность Apache FOP 1.0 — слишком много открытых файлов err24

Мы используем Apache FOP для преобразования большого количества XML в AFP и PDF. Наша текущая нагрузка будет составлять около 25 тысяч файлов за запуск в системе HP-UX. Всего у нас есть 8 потоков, которые используются для инициализации и запуска преобразования FOP в режиме производитель-потребитель. В последнее время во время преобразования было несколько сбоев, и при поиске мы получили общие ошибки FOP, такие как:

**ERROR,2460364,FOToPDF_Thread_11,FOP Exception, something.pdf,Failed to resolve font with embed-url './Fonts/arial.ttf'**

или это ошибка, из-за которой не удается загрузить файл метрик шрифта, хотя файлы не повреждены с правильными разрешениями. Создается много других PDF-файлов, поэтому это не может быть проблемой.

Мы также завершаем с:

**java.io.FileNotFoundException: /PDF/20130111130002/something.pdf (Too many open files (errno:24))**

Судя по логам и обрабатываемому объему, это похоже на проблему FOP. Я читал, что у FOP была эта проблема в прошлом с файлами шрифтов. Были случаи, когда Apache открывал каждый файл шрифта несколько раз и не закрывал дескрипторы, что приводило к большому количеству открытых файлов. Это должно было быть исправлено, но если это все еще сохраняется, что было бы хорошим и быстрым решением для этого, кроме публикации этого в списках Apache?

Можно ли увеличить максимальное количество файлов HP-UX для дескрипторов открытых файлов на процесс выше 2048? Это поможет? Любые другие предложения?


java apache apache-fop
person Joey Ezekiel    schedule 17.01.2013    source источник
comment
Вам придется попробовать запустить ulimit -n 2049, чтобы увидеть, выходит ли он за рамки этого. Но вы уже ответили на свой вопрос :)   -  person george_h    schedule 28.01.2013

Ответы (2)


arrow_upward
1
arrow_downward

Соответствующая проблема в проекте Apache FOP

https://issues.apache.org/jira/browse/FOP-2189

Как я там прокомментировал, мне не удалось идентифицировать какой-либо дескриптор открытого файла в FOP 1.0. Конструктор FontFileReader, который принимает аргумент InputStream, действительно не закрывает его, но вызывающая сторона (создавшая поток) закрывает его, см. строки 94-106

http://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-1_0/src/java/org/apache/fop/fonts/truetype/TTFFontLoader.java

person Alex Giotis    schedule 27.02.2013
comment
Продолжая свою предыдущую проблему (2189), я теперь использовал утилиту HP-UX tusc (аналогичную lsof) для мониторинга системных вызовов (в частности, открытие/закрытие дескрипторов файлов), и я заметил, что некоторые ресурсы изображений (.tif ) файлы остаются открытыми. Я использовал прослушиватель кеша изображений для отслеживания загрузки/предварительной загрузки изображений, и кеш работает нормально. Проблема в том, что последний вызов открытия системного файла для любого конкретного изображения (в данном случае .tif) остается открытым и не закрывается. - person Joey Ezekiel; 05.04.2013

arrow_upward
2
arrow_downward

Я проверил исходный код FOP. Существует класс с именем FontFileReader, который используется для чтения шрифтов истинного типа. Этот класс имеет два конструктора, как показано ниже:

/**
 * Constructor
 *
 * @param fileName filename to read
 * @throws IOException In case of an I/O problem
 */

public FontFileReader(String fileName) throws IOException {
    final File f = new File(fileName);
    InputStream in = new java.io.FileInputStream(f);
    try {
        init(in);
    } finally {
        in.close();
    }
}

/**
* Constructor
*
* @param in InputStream to read from
* @throws IOException In case of an I/O problem
*/
public FontFileReader(InputStream in) throws IOException {
    init(in);
}

Как вы можете видеть во втором конструкторе выше, входной поток не закрыт, но в конструкторе выше он явно закрыт.

Существует еще один класс под названием TTFFontLoader, который загружает шрифты ttf в память, этот класс использует второй конструктор (выделенный) для чтения файлов шрифтов, поэтому я думаю, что именно поэтому потоки остаются открытыми и должны достигать предела открытия процесса. файл обрабатывает и выдает ошибку «Слишком много открытых файлов».

Эта проблема была решена после рефакторинга подсистемы шрифтов FOP в текущей основной версии кода FOP.

person Joey Ezekiel    schedule 28.01.2013