> "...remove the «risky» class files (InvokerTransformer, InstantiateFactory, and InstantiateTransfromer) in all commons-collections jars used by your app".
Ещё из spring'а (если используете в своих приложениях) выкинуть org.springframework.beans.factory.support.AutowireUtils, ну может ещё чего найдёте (наверняка есть что-то в классах, обслуживающих xml-конфигурацию приложения). Правда, IoC в Spring после этого вряд ли взлетит.
У InvokerTransformer нет дефолтного конструктора, там все запутанее: у PriorityQueue в readObject() есть вызов compare у объекта, в качестве которого передаётся экземпляр TransformerComparator'а, который в свою очередь вызывает метод transform() у переданного InvokerTransformer. А там уже Method.invoke(), которому передаётся трэш, угар и содомия, например, Runtime.getRuntime().exec().
Так что надо искать не дефолтные конструкторы, а readObject(), которые вызывают интерфейсные методы, реализации которых где-то там в глубине стека вызывают invoke()
Для прод системы: есть много устройств в сети, которым надо обращаться, у каждого есть набор уникальных свойств/фич, этим свойствам присвоены лейблы.
Есть диспетчер, который перед стартом работы из базы вычитывает инфу по устройствам и начинает асинхронно принимать запросы от сторонних систем (у каждого из запросов набор лейблов, которыми должно обладать то или иное устройство, чтобы выполнить запрос). Диспетчер должен быстро перенаправить запрос на то или иное свободное устройство согласно информации о лейблах, дождаться ответа от устройства, и перенаправить ответ обратно.
Есть динамическое удаление устройства (например, выходит из строя, или проблемы с сетью). Но пока это редкое событие, поэтому удаление не реализовывал (потребуется перестроение bitmap-индексов), а удаленные устройства отфильтровываю по флажку недоступности.
Если бы использовал БД, то это лишние лаги и введение лишних точек отказа (линк до бд, да и сама бд).
Кстати, BiMultimap не входит в релизную ветку гуавы, соответственно та версия, которая, например, через мавен к моему проекту подтягивается, не имеет этой функциональности.
Поизучал, как работают предикаты и Multimaps.filterValues(): получается, что последовательно (с помощью Predicates.AndPredicate.apply()) накладывает условие на ярлыки по всем элементам коллекции для каждого ярлыка из запроса.
Т.е. если у нас в среднем m ярлыков в запросе, в среднем n ярлыков для каждого объекта в коллекции, и k объектов в коллекции, то временная сложность алгоритма итерирования по Multimaps.filterValues().values() будет O(k*m) (если принимаем, что Set.contains() имеет сложность O(1))
В моем же случае уже есть предрасчитанный bitmap index, который сводит временную сложность к O(m + k).
Он отнаследован от SetMultimap, метод get() которого возвращает множество значений. Вот если бы был метод, который накладывал constraint на весь BiMultimap и возвращал view, типа BiMultimap, значения которого имеют данный ярлык, то да, эта функциональность меня бы устроила.
Ещё из spring'а (если используете в своих приложениях) выкинуть org.springframework.beans.factory.support.AutowireUtils, ну может ещё чего найдёте (наверняка есть что-то в классах, обслуживающих xml-конфигурацию приложения). Правда, IoC в Spring после этого вряд ли взлетит.
Так что надо искать не дефолтные конструкторы, а readObject(), которые вызывают интерфейсные методы, реализации которых где-то там в глубине стека вызывают invoke()
Кстати, Spring и Groovy тоже под ударом, судя по этому.
Читать: NGINX только через год реализовал протокол SPDY после Jetty и Apache.
SPDY появился в develpment версии nginx-1.3.15 только 26.03.2013.
Плагин mod-spdy для apache, был выпущен в production-ready годом раньше 19.04.2012.
Есть диспетчер, который перед стартом работы из базы вычитывает инфу по устройствам и начинает асинхронно принимать запросы от сторонних систем (у каждого из запросов набор лейблов, которыми должно обладать то или иное устройство, чтобы выполнить запрос). Диспетчер должен быстро перенаправить запрос на то или иное свободное устройство согласно информации о лейблах, дождаться ответа от устройства, и перенаправить ответ обратно.
Есть динамическое удаление устройства (например, выходит из строя, или проблемы с сетью). Но пока это редкое событие, поэтому удаление не реализовывал (потребуется перестроение bitmap-индексов), а удаленные устройства отфильтровываю по флажку недоступности.
Если бы использовал БД, то это лишние лаги и введение лишних точек отказа (линк до бд, да и сама бд).
Т.е. если у нас в среднем m ярлыков в запросе, в среднем n ярлыков для каждого объекта в коллекции, и k объектов в коллекции, то временная сложность алгоритма итерирования по Multimaps.filterValues().values() будет O(k*m) (если принимаем, что Set.contains() имеет сложность O(1))
В моем же случае уже есть предрасчитанный bitmap index, который сводит временную сложность к O(m + k).