Three of us have now looked at this code and we can't see any issues like that with it:

    @Activate
void activate( ComponentContext cc, BundleContext bc, Map<String,Object> config )
    {
        logger.info( "activate" );

        thread = new Thread( this );
        thread.start();
    }


On 23/11/2016 14:58, David Daniel wrote:
An issue I had with threading was that the activate function was never completing because I had a loop waiting for the thread. I ended up moving the thread creation out of activate and using an executor to run the thread instead of a while loop which took the whole cpu. I also check to make sure the executer is null and if it is not then I kill the old thread.

        if (_executor != null) {
            _executor.shutdownNow();
            while(!_executor.isTerminated()){
            }
        }
        _executor = Executors.newSingleThreadExecutor();

            SseWriter writer = new SseWriter(eventQueue, pout, _uri);
            int circuitBreaker = 0;
            _executor.execute(writer);

            while(!writer.isStreaming() && circuitBreaker < 10 ) {
                circuitBreaker++;
                Thread.sleep(1000);
            }

            _executor.awaitTermination(5, TimeUnit.MINUTES);

On Wed, Nov 23, 2016 at 9:43 AM, Christian Schneider <ch...@die-schneider.net <mailto:ch...@die-schneider.net>> wrote:

    If you get this: "osgi.enroute.configurer.simple.provider"
    Then the configurer is still active.

    Christian


    On 23.11.2016 15:37, Tim Ward wrote:
    No difference. It still activates my @Component twice, with no
    deactivation in between, so I start two threads and one of them
    crashes.

2016-11-23 14:35:42,487 | INFO | pool-37-thread-3 | provider | 73 - osgi.enroute.configurer.simple.provider -
    2.0.0.201610141744 | Reading configurations for bundle
    com.telensa.apps.planet.p2c.provider 1.0.0.201611231201 in
    configuration/configuration.json
2016-11-23 14:35:42,487 | INFO | pool-37-thread-3 | provider | 73 - osgi.enroute.configurer.simple.provider -
    2.0.0.201610141744 | Reading configuration for bundle
    com.telensa.apps.planet.p2c.provider 1.0.0.201611231201 in
    configuration/configuration.json null
    2016-11-23 14:35:42,498 | INFO  | pool-37-thread-3 | P2cImpl    |
    74 - com.telensa.apps.planet.p2c.provider - 1.0.0.201611231201 |
    activate
    2016-11-23 14:35:42,517 | INFO  | pool-37-thread-3 | P2cImpl    |
    74 - com.telensa.apps.planet.p2c.provider - 1.0.0.201611231201 |
    activate
2016-11-23 14:35:42,517 | INFO | pool-37-thread-3 | provider | 73 - osgi.enroute.configurer.simple.provider -
    2.0.0.201610141744 | Reading configurations for bundle
    com.telensa.apps.planet.p2c.provider 1.0.0.201611231201 in
    configuration/configuration.json
2016-11-23 14:35:42,518 | INFO | pool-37-thread-3 | provider | 73 - osgi.enroute.configurer.simple.provider -
    2.0.0.201610141744 | Reading configuration for bundle
    com.telensa.apps.planet.p2c.provider 1.0.0.201611231201 in
    configuration/configuration.json null
    2016-11-23 14:35:42,522 | INFO  | Thread-47 | P2cImpl    | 74 -
    com.telensa.apps.planet.p2c.provider - 1.0.0.201611231201 |
    Thread started running
    2016-11-23 14:35:42,527 | INFO  | Thread-48 | P2cImpl    | 74 -
    com.telensa.apps.planet.p2c.provider - 1.0.0.201611231201 |
    Thread started running


    On 23/11/2016 14:15, Dirk Fauth wrote:

    I don't know how it looks like in karaf, but probably yes


    Am 23.11.2016 15:09 schrieb "Tim Ward" <t...@telensa.com
    <mailto:t...@telensa.com>>:

        Do you mean delete karaf\data and start all over again? -
        no, I haven't tried that.

        On 23/11/2016 13:38, Dirk Fauth wrote:

        Have you cleared the bundle cache in between?


        Am 23.11.2016 13:42 schrieb "Tim Ward" <t...@telensa.com
        <mailto:t...@telensa.com>>:

            I have a @Component with immediate=true which fires up
            a thread in its @Activate to listen on a socket. The
            @Deactivate, if it were ever called, would kill the thread.

            What I appear to be seeing is that the @Activate is
            called twice with no call to @Deactivate (so I get two
            threads, one of which crashes because the port is in use).

            There may be a hint that this is connected to the
            processing of configuration.json, even though there is
            nothing in configuration.json for this particular
            @Component.

            Any ideas?

            When I shut down the system some time later there *are*
            two calls to the @Deactivate method logged, which
            suggests that it is being called and the logging is
            working. If I leave out the "immediate=true" there are
            no calls to @Activate.


-- Tim Ward


        _______________________________________________
        OSGi Developer Mail List
        osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
        https://mail.osgi.org/mailman/listinfo/osgi-dev
        <https://mail.osgi.org/mailman/listinfo/osgi-dev>



    _______________________________________________
    OSGi Developer Mail List
    osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
    https://mail.osgi.org/mailman/listinfo/osgi-dev
    <https://mail.osgi.org/mailman/listinfo/osgi-dev>
-- Tim Ward

    _______________________________________________
    OSGi Developer Mail List
    osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
    https://mail.osgi.org/mailman/listinfo/osgi-dev
    <https://mail.osgi.org/mailman/listinfo/osgi-dev>

    -- Christian Schneider http://www.liquid-reality.de Open Source
    Architect http://www.talend.com

    _______________________________________________ OSGi Developer
    Mail List osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
    https://mail.osgi.org/mailman/listinfo/osgi-dev
<https://mail.osgi.org/mailman/listinfo/osgi-dev>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Tim Ward
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to