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> 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>:
>
>> 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>:
>>
>>> 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
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
> _______________________________________________
> OSGi Developer Mail
> listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> --
> Tim Ward
>
>
>
> _______________________________________________
> OSGi Developer Mail
> listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> --
> Christian Schneiderhttp://www.liquid-reality.de
>
> Open Source Architecthttp://www.talend.com
>
>
> _______________________________________________
> 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
