Hi Neil, Thanks for the tips.
> With regard to "testing bouncing", there are two sides to this question: the > component being bounced, and the other components that may be exposed to it > bouncing. > > The component itself should never actually know that it is being, or has > been, bounced. SCR always creates a new instance for each activation… Yeah, that was one of my learnings during this iteration. The simplicity of using a static component cannot be understated. By removing as much threading and dynamic components as possible, it makes the system **MUCH** more easy to reason, and at least in my case with no perceptible performance loss. > The harder question is about components that deliberately expose themselves > to the bouncing of other components – in other words, they have dynamic > service references – and/or expose themselves to dynamic configuration > changes by having a modified method. Tim talked about components that require > heavyweight initialisation... to implement such a component you might write a > modify method to accept dynamic config changes and then internally implement > some kind of damping mechanism. This gets you into some slightly hairy > multithreading code. Yeah… I’m trying to avoid that when possible. > I don't have a good answer myself yet for testing this kind of code, it seems > like even the best available practices are still quite primitive and > probabilistic, e.g. running the same code thousands of times and hoping to > find an error. I would love to find something better. I get the impression that the only thing to do is reason about the code. I am finding that there are two places where there is potential for things to go wrong: (1) concurrency due to “regular” multithreading and (2) when using promises. Concurrency is a little easier to reason, at least for me. I have tried to limit exposure to these risks as much as possible. I think I have this pretty much under control, but since I am relying on my ability to reason and don’t have a conclusive means of testing, I have no guarantee that I have not reasoned incorrectly. As for promises, the bigger challenge is protecting against services that come and go. I am finding that dealing with these dynamics is more challenging than concurrency. However, by reducing multithreading (accepting synchronous processing as much as possible instead of worrying too much in advance about performance), I have greatly reduced these risks and, at least for now, the timing problems I was having. Although I understand that it is not good practice to linger too long in, for example, an activate method, by moving back “long” processes (in the order of a second or so) synchronously into the same thread, I have greatly simplified my system, at the expense of a startup time that is about 5-10 seconds slower. I can certainly live with that. KISS Thanks again. =David
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
