Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Error handling for sync invocations in Java
09-12-2011, 04:25 PM (This post was last modified: 09-12-2011 04:33 PM by simoncn.)
Post: #31
RE: Error handling for sync invocations in Java
(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.
Find all posts by this user
12-12-2011, 10:00 AM (This post was last modified: 19-01-2012 10:43 AM by simonc.)
Post: #32
RE: Error handling for sync invocations in Java
(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.
Find all posts by this user
19-12-2011, 03:47 PM
Post: #33
RE: Error handling for sync invocations in Java
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.
Find all posts by this user


Forum Jump: