Error handling for sync invocations in Java

[simoncn]

(09-12-2011 02:15 PM)simonc Wrote:  Yes. This will indeed be misleading but won't be fatal (as the control point will always be left with a CpDevice it can use).

That's true unless B subsequently goes down for some reason. In that case the sequence would be:

deviceAdded(A)
deviceRemoved(A)
deviceAdded(B)
deviceRemoved(B)

A is still active, but there's no way for the control point to know that.

---

(09-12-2011 04:25 PM)simoncn Wrote:  That's true unless B subsequently goes down for some reason. In that case the sequence would be:

deviceAdded(A)
deviceRemoved(A)
deviceAdded(B)
deviceRemoved(B)

A is still active, but there's no way for the control point to know that.

How about sending a deviceAdded callback for B without sending a deviceRemoved callback for A? I think this allows all scenarios to work correctly:

1. If A is unplugged and replugged as B, the control point will discover that A isn't working when it next tries to make an invocation on A. At that point it can switch to B and carry on.

2. If A and B are both active simultaneously, the control point is made aware that the same device is available with two addresses and it can take advantage of that to provide redundancy/failover.

[simonc]

(09-12-2011 04:25 PM)simoncn Wrote:  How about sending a deviceAdded callback for B without sending a deviceRemoved callback for A? I think this allows all scenarios to work correctly:

ohNet is slightly deficient in its handling of multihomed devices that announce themselves at more than one address on a single subnet. I believe such devices are very rare; the conditions necessary to demonstrate ohNet's deficiency are possibly even more rare.

We will address this but its a very low priority so will probably take us a few months to find time for. Any future fix will likely be transparant to clients. Passing several devices with identical udns to clients wouldn't work at present - udn is the only way for clients to distinguish between CpDevice instances. Anyway, leaving this all to client code would make use of device lists too complex.

[simoncn]

I've been able to test this fix now. Using the 0.76 binary download, it works fine in both my test scenarios. Many thanks.