Took me awhile to track down a really weird timing bug in a binding and just want to make sure that the situation I'm about to describe is what 'should' happen as opposed to a bug...
I have a binding that has a UPNP participant discovery process. If I have previously added the thing, the existing thing will have a 'thingUpdated' called on it when it's discovered again at startup.
Now the problem:
My existing item starts it's initialization process (via initialize()). The thing is 'discovered' again and thingUpdate is called. Let's say that thingUpdate is called BEFORE the existing initialize completes - then you'd have the following:
1) initialize() started
2) thingUpdate() called
2a) dispose called
2b) initialize called
3) original initialize() finishes (and goes online)
4) second initialize() finishes
So essentially I have TWO initialize()s running at the same time. (which, in my cases, causes issues because the first one finishes and goes online BEFORE the second one finishes - and that causes the second one various issues since the thing is online before it's done).
are you initialising your Thing in a separate thread? Does your ThingHandler create a background thread to do so? In this case you should clean up this thread when the dispose method is called. This way the first run of initialize will cleanly be disposed and the 2nd run can initialise your Thing correctly.
I didn't because the initialize was only about 100ms or so (that's why it was such a hard timing issue to track down). I'll probably switch over to an interruptible initializing thread however because of this...
One other note - I'm kinda surprised there is no status change when this happens. If the first initialize completes before the thingUpdated - it will be online for the dispose/initialize of the update. There will obviously be a small amount of time between the dispose and initialize where the binding is actually in a 'not-online' status (however brief)
Okay, this rather sounds like a bug in the framework then. Would you please open an issue here? You may reference this discussion here, of course, so you can keep the description brief. I will then have a look.
Regarding the Thing's status: This is due to the fact that this dispose()-initialize() sequence actually is not done by the framework. It's in fact behavior that your handler inherited. Have a look at BaseThingHandler.thingUpdated(...). You may override this method and set the Thing's status accordingly, if you like.