karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Schmidt <ktschm...@gmail.com>
Subject Re: bundle corruption with felix and karaf 3.0.2
Date Fri, 09 Jan 2015 16:02:17 GMT
JB,

Both are commented out and from what is commented out, I assume the default
is true in both cases?  Although there is a comment that in 2.x the
start-up one was false?  We are using 3.0.2 though.

Kevin

On Thu, Jan 8, 2015 at 10:48 PM, Jean-Baptiste Onofré <jb@nanthrax.net>
wrote:

> Hi Kevin,
>
> what do you have in etc/org.apache.karaf.features.cfg ?
>
> Especially:
> respectStartLvlDuringFeatureUninstall=true
> respectStartLvlDuringFeatureStartup=true
>
> Regards
> JB
>
> On 01/09/2015 07:00 AM, Kevin Schmidt wrote:
>
>> JB,
>>
>> Thanks.
>>
>> But is there anything in place to prevent the preemptive shutdown from
>> stopping a bundle before it otherwise would be based on the start-level?
>>
>> The problem in this case is that the ActiveMQ bundle (that uses
>> blueprint) gets shutdown before message consumers (that don't use
>> blueprint), even though the consumer's start-level is higher.  So the
>> consumers end up trying to reconnect and won't shutdown.  When
>> preemptive is changed to false, the shutdown order seems to be such that
>> this problem doesn't occur.
>>
>> And this shutdown issue doesn't directly cause or avoid the corruption,
>> rather it is when Karaf doesn't shutdown due to the hung/retrying to
>> connect bundles and has to be killed that the corruption occurs.  So if
>> we can avoid having to kill the Karaf process, we avoid the corruption.
>>
>> Kevin
>>
>> On Thu, Jan 8, 2015 at 9:23 PM, Jean-Baptiste Onofré <jb@nanthrax.net
>> <mailto:jb@nanthrax.net>> wrote:
>>
>>     Hi,
>>
>>     The preemptive shutdown is specially written to avoid problems when
>>     a bean from a bundle being shut down will wait for 5 minutes for a
>>     dependency which will never come up. This is done by looking at the
>>     service dependencies and shutting down the blueprint bundles
>>     containers that have no exported services in use and iterating ...
>>
>>     So, with true, the "regular" shutdown is faster (as we don't wait 5
>>     minutes).
>>
>>     I don't thin the bundle cache corruption is related to this as it's
>>     more at framework level.
>>
>>     However, as I said, I will investigate the issue.
>>
>>     Regards
>>     JB
>>
>>
>>     On 01/09/2015 12:21 AM, asookazian2 wrote:
>>
>>         Please answer the question below regarding usage of
>>         org.apache.aries.blueprint.__preemptiveShutdown=false.  any
>>         repercussions of
>>         doing this?
>>
>>         Also, is there any documentation on this and any other system
>>         properties
>>         that are "hidden"?  Perhaps this one should be explicitly set to
>>         true/false
>>         by default in the system.properties file?
>>
>>
>>         schmke wrote
>>
>>             One case I've seen, this issue occurs when ActiveMQ is being
>>             used and gets
>>             shutdown as part of the Blueprint shutdown that doesn't seem
>>             to follow the
>>             reverse start-level shutdown.  Then AMQ clients that aren't
>>             using
>>             Blueprint
>>             have issues as they are trying to reconnect and don't
>> shutdown.
>>
>>             I found that there is a setting,
>>             org.apache.aries.blueprint.__preemptiveShutdown, which
>>
>>             defaults to true but
>>             when set to false seems to help this issue.  But what is the
>>             impact or
>>             side-effects of setting it to false?  Will the shutdown just
>>             take longer
>>             in
>>             this case?  Or is there something else to be aware of?
>>
>>             On Wed, Jan 7, 2015 at 9:30 PM, Jean-Baptiste Onofré &lt;
>>
>>
>>             jb@
>>
>>
>>             &gt;
>>             wrote:
>>
>>                 We have a Jira about that, it's related to Felix
>>                 framework and bundle
>>                 cache corruption. Just delete the cache fixes the issue
>>                 but I'm looking
>>                 for
>>                 a more reliable workaround (in Karaf).
>>
>>                 Regards
>>                 JB
>>
>>
>>                 On 01/08/2015 01:12 AM, asookazian2 wrote:
>>
>>                     Karaf 3.0.2
>>
>>                     we are seeing intermittent hanging on halt
>>                     (shutdown) of karaf.  we then
>>                     use
>>                     'kill -9' on karaf java process.  then, sometimes
>>                     after a restart, we
>>                     are
>>                     seeing some bundles (typically the last n bundles)
>>                     in 'installed' state.
>>                     I
>>                     believe I saw on this forum JB commented the root
>>                     cause of this is a
>>                     felix
>>                     bug.  Any details on this JIRA, etc. and when it may
>>                     be fixed?  Has
>>                     anybody
>>                     else seen this behavior?
>>
>>                     In the log we are seeing:
>>
>>                     20150107 15:38:22.613 [WARN ] ActiveMQ Task-3 |
>>                     147:org.apache.activemq.__activemq-osgi |
>>                     org.apache.activemq.transport.
>> __failover.FailoverTransport
>>                     | Failed to
>>                     connect
>>                     to [tcp://localhost:61616] after: 10 attempt(s)
>>                     continuing to retry.
>>
>>                     Also, i noticed today that I could not 'uninstall
>>
>>             <bundleId>
>>             ' for these
>>
>>                     corrupted bundles.  Should we just delete them
>>                     manually from
>>                     kara/data/cache/
>>
>>             <bundleId>
>>                directory and restart karaf?  thx for any help.
>>
>>
>>                     btw, we tried switching to equinox but we had other
>>                     issues with that so
>>                     back
>>                     with felix for now.
>>
>>
>>
>>                     --
>>                     View this message in context:
>>                     http://karaf.922171.n3.nabble.
>>                     com/bundle-corruption-with-__felix-and-karaf-3-0-2-__
>> tp4037669.html
>>                     Sent from the Karaf - User mailing list archive at
>>                     Nabble.com.
>>
>>
>>                 --
>>                 Jean-Baptiste Onofré
>>
>>
>>             jbonofre@
>>
>>
>>                 http://blog.nanthrax.net
>>                 Talend - http://www.talend.com
>>
>>
>>
>>
>>
>>
>>         --
>>         View this message in context:
>>         http://karaf.922171.n3.nabble.__com/bundle-corruption-with-_
>> _felix-and-karaf-3-0-2-__tp4037669p4037694.html
>>         <http://karaf.922171.n3.nabble.com/bundle-corruption-
>> with-felix-and-karaf-3-0-2-tp4037669p4037694.html>
>>         Sent from the Karaf - User mailing list archive at Nabble.com.
>>
>>
>>     --
>>     Jean-Baptiste Onofré
>>     jbonofre@apache.org <mailto:jbonofre@apache.org>
>>
>>     http://blog.nanthrax.net
>>     Talend - http://www.talend.com
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Mime
View raw message