2012-04-18 3 views
7

У меня есть требование, когда мне нужно перезагрузить пакеты osgi 4 раза в день. Перезагрузка пакета означает воссоздание статических экземпляров Beans, перезагрузку верблюжьих маршрутов, воссоздание и впрыскивание пулов потоков, пулы соединений с базами данных ..etc (другие весна xml). Я попытался обновить свои пакеты через ssh, но мне нужен идентификатор пакета для того, что может изменить сверхурочную работу. Итак, я написал менеджер Bundle, который получает пакеты с помощью символических имен и обновляет их 4 раза в деньПроблема с обновлением пакетов osgi

  osgi impl : felix 

      container : apache-servicemix-4.4.1-fuse-03-06 

      Service Dependency spec : Blueprint 

Там 3 связки вместе с помощником расслоения .The хелперов пачкой использовали все общие классов и услуги интерфейсов. Существует нет обмена кодами между этими тремя пакетами (ни один из них не экспортирует какие-либо пакеты). Все они взаимодействуют через конечные точки и службы верблюда vm. Я только обновляю остальные 3 пакета, а вспомогательный пакет не предоставляет никаких услуг.

Теперь проблема в том, когда я делаю обновление этих 3 пучков, которые они запускают и работают нормально, но каждый раз, когда я это делаю, я вижу увеличение на 800-900 классов на jconsole. Принуждение gc также не очищает эти объекты. Итак, какими могут быть эти старые проводные объекты? Зависимости служб должны обновляться автоматически, и между пакетами нет зависимостей между кодами. Я проверил разницу в количестве классов после и до обновления.

я мог видеть, что количество некоторых классов удвоилось, как org.apache.activemq.camel.component.VmComponent, org.apache.commons.dbcp.BasicDataSource ..etc и некоторые пользовательские бобы, которые я определены на моих верблюжьих маршрутах. Я зависим от контейнера для верблюжьего ядра, чертежа, кварца ... и т. Д. Что конкретно происходит с бобами, конечными точками VM ... в контексте camel и компонентами, определенными в обновлении blueprint-config xml. Я знаю, что его рекомендуется вызвать FrameworkWiring.refreshBundles() после обновления пакета. Но у меня нет обмена кодами между пакетами, и я предполагал, что какой-либо другой контейнер зависимостей должен обрабатывать то, что я думаю сейчас не так. И я не уверен, что текущая реализация фельхейма в servicemix поддерживает FrameworkWiring.refreshBundles() (ref), я не смог заставить ее работать. Как я могу исправить эту проблему?

Благодаря sanre6

+0

У вас есть темы из старого экземпляра пакета, который висит вокруг? – artbristol

+0

да, их счет удвоился. Вы пытаетесь сказать, что мне нужно закрыть мои экземпляры, отключить верблюжий маршрут до обновления пакета? – sanre6

+0

Мы обнаружили ту же проблему. Переход к реализации равноденствия устраняет эту проблему, и я подозреваю, что проблема с контейнером Felix OSGI. –

ответ

0

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

+0

мое приложение сильно зависит от пакетов servicemix, и я считаю, что лучшая практика позволяет контейнеру обрабатывать ваши зависимости, идентифицируя все эти зависимости и очищая их, будет много мучительной работы. Я даже не уверен, что вы можете удалить ядро ​​osgi и зависимостей, связанных с планом, перед обновлением пакета – sanre6

1

В целом, только при запуске обновления на пучках недостаточно. Вы должны в какой-то момент также обновить свои пакеты. Если все хорошо себя ведет, этого должно быть достаточно, чтобы обновить всю проводку пакетов, эффективно разрешив сборку старых версий пакета. Однако, если в одном из пакетов, которые не ведут себя хорошо, что-то происходит, и поддерживает поток или некоторые ресурсы в кеше или что-то еще, вы должны начать отслеживать проблему. Получите себя хорошим профилировщиком, посмотрите, что такое пучок и загрузчик классов, к которым эти «дополнительные» объекты принадлежат и идут оттуда.