большие "вложения"
Имеется некая система, которая помимо прочего работает с "вложениями" - аналог почтового аттача.
Некоторое время назад заказчик пожелал передавать через эти вложения большие объемы данных - 500Мб и более. Причем суть процесса такова, что вложение может быть запаковано, зашифровано, подписано и т.д. - и в памяти с ними работать совершенно нереально, ибо память улетает как вода в песок.
Подумали и решили перевести все на использование временных файлов и потоков.
Возникли такие вопросы:
1. Какие есть стандартные способы управлять такими файлами? Сервер тушится редко - делать deleteOnExit() бессмысленно. Перекрывать finalize() и в нем грохать неиспользуемый временный файл не удалось, GC по непонятным пока причинам не вызывает этот метод. В итоге временные файлы могут плодиться как кролики... Сейчас удаляем файл при закрытии потока, но кода много и сходу гарантировать, что кто-нить не забыл закрыть поток - сложно.
2. Известны ли какие-нить хитрые способы решить проблему двойного вычитывания таких потоков? Т.е. если некий "сторонний" код с помощью некоего API получил такой поток и вычитал его, то другой код при попытке читать поток получит -1 или начнет читать откуда-то с середины.
Короче, имеющееся решение выглядит как некий костыль, немного от него коробит. Хочется более красивого решения.
Подумалось, что наверняка кто-то что-то подобное уже пытался сделать...
Буду благодарен за любые идеи, как правильно и гибко работать с большими массивами данных.
Некоторое время назад заказчик пожелал передавать через эти вложения большие объемы данных - 500Мб и более. Причем суть процесса такова, что вложение может быть запаковано, зашифровано, подписано и т.д. - и в памяти с ними работать совершенно нереально, ибо память улетает как вода в песок.
Подумали и решили перевести все на использование временных файлов и потоков.
Возникли такие вопросы:
1. Какие есть стандартные способы управлять такими файлами? Сервер тушится редко - делать deleteOnExit() бессмысленно. Перекрывать finalize() и в нем грохать неиспользуемый временный файл не удалось, GC по непонятным пока причинам не вызывает этот метод. В итоге временные файлы могут плодиться как кролики... Сейчас удаляем файл при закрытии потока, но кода много и сходу гарантировать, что кто-нить не забыл закрыть поток - сложно.
2. Известны ли какие-нить хитрые способы решить проблему двойного вычитывания таких потоков? Т.е. если некий "сторонний" код с помощью некоего API получил такой поток и вычитал его, то другой код при попытке читать поток получит -1 или начнет читать откуда-то с середины.
Короче, имеющееся решение выглядит как некий костыль, немного от него коробит. Хочется более красивого решения.
Подумалось, что наверняка кто-то что-то подобное уже пытался сделать...
Буду благодарен за любые идеи, как правильно и гибко работать с большими массивами данных.
