'Lo. On 2016-08-09T09:32:57 +0200 Peter Kriens <peter.kri...@aqute.biz> 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/tcp_server/TCPServerService.java#L47 > > > a) You will get an automatic retry by DS but then you’re component is > dead when it runs in a problem.
Hm! This is news to me. Could you elaborate a bit on this? I've not yet experienced/learned about automatric retries for DS components. Is there some specific way I should be writing components to take advantage of this? > b) At certain network problems you will overload the log, at least > insert ’some’ delay I'm not sure which commit you saw, but there's an exponential backoff now. It retries up to n times (where n = 5 at the moment), delaying each retry for 2^n seconds. After that, it simply rethrows whatever the last exception was. > c) the server dies at certain network problems and will never recover > because you create the server socket in the constructor and not in a > loop > > OSGi is a server model, you should write your servers to run forever. > There is no reason to bail out ever before you’re stopped. This was > the primary pain point of Blueprint where the application termed into > zombie state if you were not quick enough. I see what you're saying, but there's a flip side to this approach too. The issue as I see it is that the network functions (bind() in particular) can fail for reasons that are effectively permanent. In other words, in a lot of server configurations, if bind() fails to due to EADDRINUSE or EADDRNOTAVAIL, then that's something that's likely due to a configuration problem and is just not going to change however many times the operation is retried. It seems like it'd be better to crash and let the administrator actually know about it rather than looping and writing error messages in the hope that somebody notices. I admit this philosophy applies more to systems that can't be dynamically reconfigured, unlike OSGi. > Ericsson I can see a lot of parallels between OSGi and Erlang's actor model (expect failure, recover, otherwise crash and escalate failure and assume that a supervisor component will restart me). > So yes, you’re pedantic :-), but that is the only way to make > progress because we should always challenge the way we work to > improve it. I therefore do appreciate these questions. I hope you > found my answers just as useful. I have. Thanks for taking the time! M
pgppy1SFyyydL.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
