What you’re doing is fine, as long as the deactivate method stops the thread,
and blocks until it has stopped.
The activate method will only be called once by DS for a given component, two
obvious things to ask:
Are there any places in your code where calls are made to activate?
Are you sure that there’s only one component instance being created?
For the second point, in addition to multiple configurations (as pointed out by
others on this thread) there are some other reasons that you might have more
than one component instance. You may, for example, have DS installed twice in
your runtime. You don’t appear to be using any DS 1.3 features, so it’s
unlikely that you have an extender requirement to help sort that particular
problem out. Another possibility is that the component exists in two bundles,
both of which are installed.
I hope that these pointers help you to identify what is going wrong!
Regards,
Tim
> On 23 Nov 2016, at 15:08, Tim Ward <t...@telensa.com> wrote:
>
> 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 <http://www.liquid-reality.de/>
>>
>> Open Source Architect
>> http://www.talend.com <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 <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
> 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
