Ребята, доброго времени дня/ночи суток!

Посоветуйте, что взять бы такое для реализации следующей задачки.

Есть проект "Система хранения документов" (ECM) - довольно большая и монструозная. Появилась такая задача:
пользователь открывает документ, в документе может быть несколько аттачей (png, doc, jpeg, что угодно). И пользователь может навигировать по этим аттачам в веб интерфейсе: выбирает аттач, мы его конвертируем в pdf (используем aspose) и показываем в pdf.js viewer. Все шикарно работает. Пользователь выбирает следующий аттач - мы конвертируем - показываем.
Так вот нужно улучшить. Когда пользователь открывает очередной документ, мы хотим заранее конвертнуть и закешировать все аттачи этого документа (такой precache получается). Так вот для конвертации всех аттачей надо запустить несколько потоков параллельно, по потоку на аттач, и результат конвертации сохранить где-то в кеше.
В принципе, проблемы никакой нет в реализации. Но хочется ведь взять что-нибудь готовое уже.
Для кеширования в приложении я давно хочу взять ehcache. Думаю тут самое время (сейчас используем свои механизмы кеширования всего что есть, кешируем в памяти). Собственно вопрос: может кто что посоветует для решения такой задачи? Чтобы можно было запускать сбор данных в несколько потоков и кешировать результат, и при этом не выходить из рамок ресурсов (ограничить число потоков и памяти для кеша). Я имею ввиду что-нибудь готовое, чтобы не городить огород.

Relic Hunter,

Ну смотрите, мы с помощью aspose конвертируем то, что можно, в pdf сперва (png -> pdf, doc -> pdf и т.д.), а потом, уже имея pdf, показываем его в pdf.js

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

Relic Hunterrabiter,

pdf.js это клиентская технология, а не серверная. Сохраняйте сразу в pdf и пусть "клеент" конвертирует.

Конвертация происходит на сервере, браузеру отдаем уже сконвертированный pdf

Petro123Палка о двух концах.
Есть такое в эксплорере - загружать заранее все ссылки что есть на странице.
Я это всегда выключаю. Нафига загружать всё подряд?

У нас есть ТЗ от одного из кастомеров на precache. Надо делать)

Petro123Делайте для всех доков превью в jpeg 60 DPI.
Это статика, и загрузится сразу и мгновенно.

Удобнее работать через pdf.js - можно листать страницы мышкой, зумить, копировать текст и т.д.
Мы от картинок ушли из-за этого.

Андрей ПанфиловrabiterЕсть проект "Система хранения документов" (ECM) - довольно большая и монструозная.
...
В принципе, проблемы никакой нет в реализации. Но хочется ведь взять что-нибудь готовое уже.
Для кеширования в приложении я давно хочу взять ehcache. Думаю тут самое времяМде, ECM у вас, скажем прямо, так себе. То что вы хотите в ECM называется rendition и имеет тенденцию храниться не в каком-то кеше, а в вместе с остальными файлами/метаданными, и генерироваться (и сохраняться) либо по запросу, либо после сохранения основного документа.

Есть у нас rendition, есть кастомеры, у которых мы все аттачи конвертируем в pdf и храним эти pdf вместе с оригинальными аттачами в хранилище. Но кастомеров много, не все могут позволить себе большие хранилища, чтобы в них хранить экстра данные, вот для них нужен небольшой прекеш в памяти, о котором я написал.
И опять же, действительно, у некоторых кастомеров бывают user specific watermarks, так что получается user specific кеш должен быть.

Андрей Панфиловrabiterpng, doc, jpeg, что угодно ... и при этом не выходить из рамок ресурсовУдачи, у aspose генерация "толстых" документов тупит так, что какой-нить ворд на 600 страниц конвертируется по 10 минут и выжирает весь процессор, так что вы описываете - это потенциальный DoS.
Ну в реальности редко бывают аттачи картинки, это я для примера скинул. Вообще aspose не я выбирал, и корвертацию всего и вся в pdf, Я когда узнал об этом, удивился немного, ну да ладно. Но, кстати, doc Война и Мир (4 мегабайта на 1700 страниц) конвертируется в PDF на моем ноуте за 7 секунд. Но у нас для каждого документного типа можно выставить трешхолд на превью. Часто бывают аттачи маленькие совсем.

Андрей ПанфиловmaytonНе совсем понятен юзкейс. Будет ли пользователь редактировать документы.ТС хочет все документы которые есть в системе отображать в режиме просмотра через iframe с pdf.js - типа так универсально получается (в целом можно все в pdf не конвертировать, а к примеру pdf крутить через pdf.js, картинки как есть, офис через onlyoffice какой-нить, но мороки какбы больше)
верно, универсальность. Кастомеров много, у всех свои use cases, у кого много маленьких аттачей, у кого-то мало, но большие. Все у нас настраивается, какие типы файлов конвертировать в pdf, какие нет, у какиз будет preview, у каких нет, по типам, по размерам.
pdf.js у нас как плагин вообще дефолтный, отдельные кастомеры используют свой вьювер.
Главное, в будущем если будет необходимость мы можем для разных типов аттачей использовать разные вьюверы. Но пока вот pdf.js

Андрей ПанфиловPetro123зато понадобился кеш. Обратная сторона.там кейсов довольно много можно накидать, к примеру у документа гриф ДСП стоит и пользаку нужно его отдавать модифицированным (от банальных водяных знаков, до игры со шрифтами, кириллицой/латинцией и пр.) чтобы понять кто документ слил.
Да, так и есть, каждому пользователю может отдаваться аттач со специфичным watermark.

maytonНе совсем понятен юзкейс. Будет ли пользователь редактировать документы.
А так - можно плюсануть к кешированию картинок.

Редактировать нет, но вот листать колесиком мышки страницы, зумить, копировать текст - look and feel намного приятнее чем если тебе дают картинку понюхать.

maytonАвтор что-то over-проектировал. Тут определённо нужно обсуждать саму задачу.
Причем не на уровне "я хочу" а на уровне чего на самом деле нужно бизнес-пользователю.

Преобразование картинок в pdf выглядит уж-точно какой-то гипертрофированной задачей.

Да, преобразование картинок в pdf это огонь, согласен :D

maytonДа. А если цель стоит - ставить watermark на все документы - тогда кеш будет поделен
по горизонтали на количество пользователей. Вобщем как всегда или скорость или секюрность.
Надо выбирать. Мдя.

Вооот, все верно подметили, получается кеш user specific. Ну тут нужна золотая середина. Я хочу как можно более safe решение, такой маленький кеш, для кеширования маленьких аттачей и не больше N штук на пользователя (на большие аттачи сделаем настраиваемый threshold). Кастомеров много, у всех своя специфика данных.

qastarabiterРебята, доброго времени дня/ночи суток!

Посоветуйте, что взять бы такое для реализации следующей задачки.

Так вот для конвертации всех аттачей надо запустить несколько потоков параллельно, по потоку на аттач, и результат конвертации сохранить где-то в кеше.

Лучше запустить один поток на пользователя (а не на аттач), который последовательно подготовит все аттачи


Точно! Я вчера уже засыпал, подумал, зачем по потоку на аттач, в реальности может получится медленнее. Пусть будет один поток на пользователя, который последовательно будет конвертировать. К тому же можно будет прервать процесс между аттачами, если пользователь другой документ выбрал. Да и мороки меньше с многопоточкой - один поток легче захендлить.


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

С точки зрения "прямващевсёужереализованоиготово" думаю, что нет смысла искать, т.к. черновой вариант напишется максимум за день (с перекурами и перерывами на кофе/сон) :)

Берите ehcache - штука очень гибкая и мощная: в том числе и на диск из памяти сможет сбрасывать при определенных условиях, различные варианты "устаревания" кеша, работает уже давно в промышленных средах. Интегрируется в проекты ну очень легко.

Да, я ehcache уже оценил!