OpenHome Forum
Error handling for sync invocations in Java - Printable Version

+- OpenHome Forum (http://forum.openhome.org)
+-- Forum: OpenHome (/forumdisplay.php?fid=1)
+--- Forum: Net (/forumdisplay.php?fid=5)
+--- Thread: Error handling for sync invocations in Java (/showthread.php?tid=506)

Pages: 1 2 3 4


RE: Error handling for sync invocations in Java - simoncn - 02-12-2011 05:15 PM

(02-12-2011 04:16 PM)simonc Wrote:  While it'd be preferable for the device list to automatically handle this case, note that you can handle it in client code without restarting the cp stack. You should be able to listen for changes in available subnets and manually select a previously active subnet when it reappears. (Sorry, I'm not sure of the Java APIs for this off-hand.)

If you're referring to the following fields in InitParams:
SubnetListChangedListener
SubnetAddedListener
SubnetRemovedListener
the setter functions for these are commented out in the Java version of InitParams (along with a few other InitParams fields). I presume this means that it isn't currently possible to recover from this situation if the control point is written in Java.

I'm tempted to have a go at adding the missing code if it would solve this problem. Before I do this, I'd like to clarify what it means when a client gets a "subnet added", "subnet removed" or "subnet list changed" event. If I unplug or replug the server, I wouldn't expect this to change the available subnets for the client, as the only effect has been to remove or add a single server device. Could you expand on this a little more, please?

Simon


RE: Error handling for sync invocations in Java - simonc - 05-12-2011 09:08 AM

(02-12-2011 05:15 PM)simoncn Wrote:  I'm tempted to have a go at adding the missing code if it would solve this problem. Before I do this, I'd like to clarify what it means when a client gets a "subnet added", "subnet removed" or "subnet list changed" event. If I unplug or replug the server, I wouldn't expect this to change the available subnets for the client, as the only effect has been to remove or add a single server device. Could you expand on this a little more, please?

Ah, you're correct. Assuming your control point and server are on different physical machines, unplugging the server won't result in any subnet changes being delivered to the control point. I'm surprised it results in any change at all for the control point. In which cases do the device added or removed callbacks you registered get called?


RE: Error handling for sync invocations in Java - simoncn - 05-12-2011 04:26 PM

(05-12-2011 09:08 AM)simonc Wrote:  Ah, you're correct. Assuming your control point and server are on different physical machines, unplugging the server won't result in any subnet changes being delivered to the control point. I'm surprised it results in any change at all for the control point. In which cases do the device added or removed callbacks you registered get called?

Yes, the control point and server are on different machines. I've traced the deviceAdded and deviceRemoved calls, as well as the addRef and removeRef calls from my application. There are two sequences, one failing and one working.

First, the failing sequence (on the control point):

1. deviceAdded callback invoked for server device
2. control point application calls addRef for server device
3. unplug server cable
4. replug server cable
5. control point application invokes a service on the server
6. ohNet returns ProxyError
7. control point application calls removeRef for server device
8. control point application refreshes the device list
9. deviceRemoved callback invoked for server device
10. control point application refreshes the device list again
(no further deviceAdded or deviceRemoved callbacks are made)

At this point, the control point has lost contact with the server, and any further refreshes of the device list have no effect.

Second, the working sequence (on the control point):

1. deviceAdded callback invoked for server device
2. control point application calls addRef for server device
3. unplug server cable
(don't replug the server cable yet)
4. control point application invokes a service on the server
5. ohNet returns ProxyError
6. control point application calls removeRef for server device
7. now replug the server cable
8. control point application refreshes the device list
9. deviceRemoved callback invoked for server device
10. control point application refreshes the device list
11. deviceAdded callback invoked for server device

At this point, the control point has regained contact with the server, and everything is working normally. The only difference from the failing sequence is that the control point application made a service invocation for the server while the server cable was unplugged.


RE: Error handling for sync invocations in Java - simonc - 06-12-2011 11:19 AM

(05-12-2011 04:26 PM)simoncn Wrote:  Yes, the control point and server are on different machines. I've traced the deviceAdded and deviceRemoved calls, as well as the addRef and removeRef calls from my application. There are two sequences, one failing and one working.

I've just fixed a bug where device lists wouldn't update a device that changed location without sending a byebye for its old location. This is likely to be related to your problem but may not be the whole story as I can't think why it'd allow one of your sequences to work.

As usual, my change should be on github this evening.


RE: Error handling for sync invocations in Java - simoncn - 07-12-2011 09:52 AM

(06-12-2011 11:19 AM)simonc Wrote:  I've just fixed a bug where device lists wouldn't update a device that changed location without sending a byebye for its old location. This is likely to be related to your problem but may not be the whole story as I can't think why it'd allow one of your sequences to work.

As usual, my change should be on github this evening.

Thanks for this. I've just checked on github and I don't see it there yet.


RE: Error handling for sync invocations in Java - simonc - 07-12-2011 10:48 AM

(07-12-2011 09:52 AM)simoncn Wrote:  
(06-12-2011 11:19 AM)simonc Wrote:  As usual, my change should be on github this evening.

Thanks for this. I've just checked on github and I don't see it there yet.

Our release process failed last night. Each evening, we kick off a set of builds/tests. If these all pass the latest code gets pushed to github; if any fail, github is left unchanged. This means that github can fall slightly behind but ensures the published code meets some minimum quality standard.

I'm looking into the cause of the failures now.


RE: Error handling for sync invocations in Java - simoncn - 08-12-2011 11:05 AM

(07-12-2011 10:48 AM)simonc Wrote:  
(07-12-2011 09:52 AM)simoncn Wrote:  
(06-12-2011 11:19 AM)simonc Wrote:  As usual, my change should be on github this evening.

Thanks for this. I've just checked on github and I don't see it there yet.

Our release process failed last night. Each evening, we kick off a set of builds/tests. If these all pass the latest code gets pushed to github; if any fail, github is left unchanged. This means that github can fall slightly behind but ensures the published code meets some minimum quality standard.

I'm looking into the cause of the failures now.

Thanks. I'll look forward to trying this when it's ready for prime time Smile


RE: Error handling for sync invocations in Java - simonc - 09-12-2011 11:43 AM

(07-12-2011 10:48 AM)simonc Wrote:  
Quote:Thanks for this. I've just checked on github and I don't see it there yet.

I'm looking into the cause of the failures now.

I've fixed this now so the updates should hopefully appear on github this evening.

Ths most interesting change I've made is to assume that a device has moved if we receive an announcement for it with a new location for its device xml. (This is what clients would see if we pulled out the network cable of the machine hosting the device stack, then reinserted it later.) When we decide a device has moved, we run the Removed callback for it then an Added callback for a device with the same UDN but a different xml location. This will ensure that clients are prompted to update their proxies and subscriptions (which may need to point towards new addresses for control and eventing).

In theory, this seemed like a no brainer. In practice however, its not so straightforward. Asset and some versions of twonky are capable of sending out multiple announcements for different addresses, all of which are valid. ohNet reacts to this by running Removed/Added messages each time an announcement is received.

I still tend to think that ohNet's behaviour is reasonable but we'll have to see how disruptive it proves...


RE: Error handling for sync invocations in Java - simoncn - 09-12-2011 01:54 PM

(09-12-2011 11:43 AM)simonc Wrote:  I've fixed this now so the updates should hopefully appear on github this evening.

Thanks!

Quote:In theory, this seemed like a no brainer. In practice however, its not so straightforward. Asset and some versions of twonky are capable of sending out multiple announcements for different addresses, all of which are valid. ohNet reacts to this by running Removed/Added messages each time an announcement is received.

I still tend to think that ohNet's behaviour is reasonable but we'll have to see how disruptive it proves...


Does this mean that if Asset sends out two announcements for address A and then for address B, ohNet will run the following callbacks:
deviceAdded(A)
deviceRemoved(A)
deviceAdded(B)

If so, this seems to be misleading from the control point's perspective because it appears that A has gone away, which isn't the case. Or would ohNet do the following:
deviceAdded(A)
deviceRemoved(A)
deviceAdded(A)
deviceAdded(B)

This is also likely to be confusing/disruptive for the control point if it is currently communicating with the device using address A.


RE: Error handling for sync invocations in Java - simonc - 09-12-2011 02:15 PM

(09-12-2011 01:54 PM)simoncn Wrote:  Does this mean that if Asset sends out two announcements for address A and then for address B, ohNet will run the following callbacks:
deviceAdded(A)
deviceRemoved(A)
deviceAdded(B)

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). This should only happen in certain rare cases
  • a particular, buggy, version of Twonky
  • Asset hosted on a PC with 2 or more network cards which are active and on the same subnet
I can find both on Linn's network but suspect the vast majority of media server users won't have either so won't be affected in the slightest.