Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline andrey.d  
#1 Оставлено : 28 ноября 2019 г. 13:51:49(UTC)
andrey.d

Статус: Новичок

Группы: Участники
Зарегистрирован: 28.11.2019(UTC)
Сообщений: 4

Добрый день. Словили ошибку "Too many open files" при очередном вызове Java-метода получения ключа из хранилища:

PrivateKey key = (PrivateKey) keyStore.getKey(alias, password);

Caused by: java.io.FileNotFoundException: .../masks.key (Too many open files)
at java.io.FileInputStream.open0(Native Method) ~[?:1.8.0_121]
at java.io.FileInputStream.open(FileInputStream.java:195) ~[?:1.8.0_121]
at java.io.FileInputStream.<init>(FileInputStream.java:138) ~[?:1.8.0_121]
at ru.CryptoPro.JCP.KeyStore.HDImage.cl_0.readFile(Unknown Source) ~[JCP.jar:39442]
at ru.CryptoPro.JCP.KeyStore.ContainerEncoder.readMasks(Unknown Source) ~[JCP.jar:39442]
at ru.CryptoPro.JCP.KeyStore.cl_4.a(Unknown Source) ~[JCP.jar:39442]
at ru.CryptoPro.JCP.KeyStore.cl_4.a(Unknown Source) ~[JCP.jar:39442]
at ru.CryptoPro.JCP.Key.PrivateKeySpec.a(Unknown Source) ~[JCP.jar:39442]
at ru.CryptoPro.JCP.Key.PrivateKeySpec.read(Unknown Source) ~[JCP.jar:39442]
at ru.CryptoPro.JCP.KeyStore.cl_7.run(Unknown Source) ~[JCP.jar:39442]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_121]
at ru.CryptoPro.JCP.KeyStore.cl_4.d(Unknown Source) ~[JCP.jar:39442]
at ru.CryptoPro.JCP.KeyStore.cl_4.a(Unknown Source) ~[JCP.jar:39442]
at ru.CryptoPro.JCP.KeyStore.ContainerStore.a(Unknown Source) ~[JCP.jar:39442]
at ru.CryptoPro.JCP.KeyStore.ContainerStore.engineGetKey(Unknown Source) ~[JCP.jar:39442]
at ru.CryptoPro.JCP.KeyStore.JCPKeyStore.engineGetKey(Unknown Source) ~[JCP.jar:39442]
at java.security.KeyStore.getKey(KeyStore.java:1023) ~[?:1.8.0_121]
at ...SignService.sign(SignService.java:48) ~[classes!/:?]
... 97 more

Версия Java: 8.0.121, версия КриптоПРО: JCP/JTLS 2.0.39442.

После перезагрузки ошибка временно ушла. Есть предположение, что причина - баг в данной версии КриптоПРО (возможно, где-то не закрываются вовремя файлы и т.п.). Не подскажете, так ли это, и, если да, то не пофикшена ли ошибка в более новых сборках?
Offline Евгений Афанасьев  
#2 Оставлено : 29 ноября 2019 г. 19:49:21(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,910
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 685 раз в 646 постах
Добрый день.
Ни разу не сталкивались с подобной ошибкой. Как её воспроизвести?
Offline andrey.d  
#3 Оставлено : 2 декабря 2019 г. 11:31:05(UTC)
andrey.d

Статус: Новичок

Группы: Участники
Зарегистрирован: 28.11.2019(UTC)
Сообщений: 4

Насколько мы поняли - нужно просто выставить относительно низкий лимит количества открытых файлов (ulimit -n) и вызвать метод keyStore.getKey(alias, password) большее количество раз, чем выставленный лимит. По крайней мере, в нашем случае каких-либо специальных условий воспроизведения не наблюдалось, просто в определенный момент очередная операция getKey вызвала такую ошибку, и она сразу же перестала воспроизводиться после перезагрузки.
Offline Евгений Афанасьев  
#4 Оставлено : 2 декабря 2019 г. 11:55:20(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,910
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 685 раз в 646 постах
Если сделать так, что количество открываемых в единицу времени файлов (а их больше 5 на контейнер) будет больше лимита, то да, получим ошибку, если к тому же закрытие происходит не сразу.
Offline andrey.d  
#5 Оставлено : 2 декабря 2019 г. 12:36:44(UTC)
andrey.d

Статус: Новичок

Группы: Участники
Зарегистрирован: 28.11.2019(UTC)
Сообщений: 4

Получается, что если интенсивность запросов высокая, то единственный способ гарантированно избежать этой ошибки - закэшировать нужную информацию из KeyStore на уровне класса и минимизировать количество вызовов keyStore.getKey()? Но в этом случае возникает вопрос: потокобезопасны ли реализации соответствующих интерфейсов (X509Certificate, PrivateKey) в данной версии КриптоПРО?
Offline Евгений Афанасьев  
#6 Оставлено : 2 декабря 2019 г. 12:45:29(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,910
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 685 раз в 646 постах
Автор: andrey.d Перейти к цитате
Получается, что если интенсивность запросов высокая, то единственный способ гарантированно избежать этой ошибки - закэшировать нужную информацию из KeyStore на уровне класса и минимизировать количество вызовов keyStore.getKey()? Но в этом случае возникает вопрос: потокобезопасны ли реализации соответствующих интерфейсов (X509Certificate, PrivateKey) в данной версии КриптоПРО?

Если кол-во одновременно открытых файлов ограничено каким-то пределом, то нужно снижать кол-во обращений к контейнерам (видимо, идет обращение к большому кол-ву контейнеров) в единицу времени. Это касается не только ключевых контейнеров, но и любых файлов, т.к. в контейнере находится N обычных файлов. В остальном доступ к контейнеру (к его файлам) синхронизирован на уровне провайдера и разграничен между пользователями. Можно кэшировать информацию или увеличить лимит.

Offline andrey.d  
#7 Оставлено : 2 декабря 2019 г. 13:04:05(UTC)
andrey.d

Статус: Новичок

Группы: Участники
Зарегистрирован: 28.11.2019(UTC)
Сообщений: 4

Окей, спасибо за помощь.
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.