Re: [osgi-dev] Waiting in deactivate/activate()?

2016-09-11 Thread Kübler , Jens
Hi, However, I would not bother, making your server loop resilient by reinitializing after a failure is much more robust against many more error cases. The chance that you get overlapping T1.deactivate/T2.activate is in my experience magnitudes smaller than getting a network problem, which in t

Re: [osgi-dev] Waiting in deactivate/activate()?

2016-08-15 Thread Peter Kriens
> On 9 aug. 2016, at 11:53, list+org.o...@io7m.com wrote: > 'Lo. > On 2016-08-09T09:32:57 +0200 > Peter Kriens wrote: >> >>> On 8 aug. 2016, at 17:02, list+org.o...@io7m.com wrote: >>> It is in fact what I ended up putting into the example: >>> https://github.com/io7m/osgi-example-reverser/blob/m

Re: [osgi-dev] Waiting in deactivate/activate()?

2016-08-09 Thread list+org . osgi
'Lo. On 2016-08-09T09:32:57 +0200 Peter Kriens wrote: > > > On 8 aug. 2016, at 17:02, list+org.o...@io7m.com wrote: > > > > It is in fact what I ended up putting into the example: > > > > > > https://github.com/io7m/osgi-example-reverser/blob/master/tcp-server/src/main/java/com/io7m/reverser/t

Re: [osgi-dev] Waiting in deactivate/activate()?

2016-08-09 Thread Peter Kriens
> On 8 aug. 2016, at 17:02, list+org.o...@io7m.com wrote: > 'Ello. > On 2016-08-08T15:11:05 +0200 > Peter Kriens wrote: >> As you seem to have found out the problems disappears when you just >> do the simple thing … block until your resource R is ready. > On this implementation, for this problem,

Re: [osgi-dev] Waiting in deactivate/activate()?

2016-08-08 Thread list+org . osgi
'Ello. On 2016-08-08T15:11:05 +0200 Peter Kriens wrote: > As you seem to have found out the problems disappears when you just > do the simple thing … block until your resource R is ready. On this implementation, for this problem, sure! :D It is in fact what I ended up putting into the example:

Re: [osgi-dev] Waiting in deactivate/activate()?

2016-08-08 Thread Peter Kriens
As you seem to have found out the problems disappears when you just do the simple thing … block until your resource R is ready. So now we have the case that you raise: T1 is deactivated while T2 is activated before T1 has finished deactivating. Looking at the SCR/DS implementations and activiti

Re: [osgi-dev] Waiting in deactivate/activate()?

2016-08-08 Thread list+org . osgi
On 2016-08-08T09:48:49 +0200 Peter Kriens wrote: > > Correctness before performance. That's a sentiment I can get behind. For the purposes of the discussion: I'm not interested in the performance implications of the subject we're discussing, only the correctness issues. > The trick in my experie

Re: [osgi-dev] Waiting in deactivate/activate()?

2016-08-08 Thread Peter Kriens
> Am I missing something here? If anything that you should not block in activate/deactivate. The crux in OSGi is to NEVER have statics and represent any entity as a dynamic service. In 99% of the case I’ve seen you can do all the activation/deactivation in the activate/deactivate method. If it b

Re: [osgi-dev] Waiting in deactivate/activate()?

2016-08-08 Thread Peter Kriens
I think the following statement is not correct: It is indeed part of the spec that a component should avoid blocking in activate/deactivate callbacks: a DS implementation might actually skip and/or blacklist a component that takes too much time to activate or deactivate. Thought it is better for

Re: [osgi-dev] Waiting in deactivate/activate()?

2016-08-07 Thread Simon Chemouil
list+org.o...@io7m.com a écrit le 07/08/2016 22:36 : > The more I think about this, the less it seems like a DS issue and more > like something more fundamental instead. DS could help create write less code by exposing more functionality, but the general solution would remain the same. For instan

Re: [osgi-dev] Waiting in deactivate/activate()?

2016-08-07 Thread list+org.osgi
On 2016-08-07T17:37:59 +0200 Simon Chemouil wrote: > > Ideally, TCPServerManager's thread dealing with binding/closing sockets > should not be held statically, but it's a bit tricky to deal with the > restarting of TCPServerManager instances otherwise. The more I think about this, the less it see

Re: [osgi-dev] Waiting in deactivate/activate()?

2016-08-07 Thread list+org . osgi
On 2016-08-07T17:37:59 +0200 Simon Chemouil wrote: > list+org.o...@io7m.com a écrit le 07/08/2016 14:01 : > > Hello. > > Hi, > > > As a learning exercise, I've put together a very contrived example of a > > "reverse" service (like an echo service, except that each returned line > > comes back

Re: [osgi-dev] Waiting in deactivate/activate()?

2016-08-07 Thread Simon Chemouil
Simon Chemouil a écrit le 07/08/2016 17:37 : >public void register(TCPServer tcpServer) { > > this.tcpServer = tcpServer; > > // blocking code. > reg = context.registerService(TCPServer.class, tcpServer, null); > > // this thread will potentially activate components d

Re: [osgi-dev] Waiting in deactivate/activate()?

2016-08-07 Thread Simon Chemouil
list+org.o...@io7m.com a écrit le 07/08/2016 14:01 : > Hello. Hi, > As a learning exercise, I've put together a very contrived example of a > "reverse" service (like an echo service, except that each returned line > comes back reversed). Mostly, I'm using it as a learning example of how > to buil

Re: [osgi-dev] Waiting in deactivate/activate()?

2016-08-07 Thread list+org . osgi
Hi. On 2016-08-07T16:26:16 +0200 wrote: > Hello, > > Although it is not good practice to sleep/block I think it is natural to wait > till the component is shut down. Right. I think it's a matter of interpretation. The compendium spec doesn't seem to say one way or the other. I think if the c

Re: [osgi-dev] Waiting in deactivate/activate()?

2016-08-07 Thread ecki
Hello, Although it is not good practice to sleep/block I think it is natural to wait till the component is shut down. On the other hand startup problems with port binding code are so common, it does not hurt to code this in a retrying thread as well. Then the started server will recover from t

[osgi-dev] Waiting in deactivate/activate()?

2016-08-07 Thread list+org . osgi
Hello. As a learning exercise, I've put together a very contrived example of a "reverse" service (like an echo service, except that each returned line comes back reversed). Mostly, I'm using it as a learning example of how to build a small TCP/IP client/server in OSGi. There are five bundles: