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é <[email protected]
<mailto:[email protected]>> 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é
    [email protected] <mailto:[email protected]>

    http://blog.nanthrax.net
    Talend - http://www.talend.com



--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply via email to