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


Error handling for sync invocations in Java - simoncn - 26-11-2011 04:55 PM

The generated code for Java proxies seems to treat errors differently for sync and async calls. For sync calls, there is code like this:

sync.waitToComplete();
try
{
sync.reportError();
}
catch (ProxyError pe) { }
return sync.getSearchCaps();

and for async calls, there is code like this:

if (Invocation.error(aAsyncHandle))
{
throw new ProxyError();
}
int index = 0;
String searchCaps = Invocation.getOutputString(aAsyncHandle, index++);
return searchCaps;

It appears that the async code throws a ProxyError back to user code if an error occurs in the invocation, but the sync code checks for an invocation error and catches and ignores the thrown exception.

I looked at the C# code and this seems to throw errors back to user code in both the sync and async cases.

Is my impression as stated above correct? If so, is there some reason why the sync code for Java doesn't report invocation errors back to user code?

Simon


RE: Error handling for sync invocations in Java - simonc - 28-11-2011 09:00 AM

This sounds like a bug in the sync Java actions. We'll get it fixed.

Gregg, who wrote all our Java code to date, has returned to uni so bear with us if it takes a bit longer than normal to address this.


RE: Error handling for sync invocations in Java - simoncn - 28-11-2011 03:44 PM

(28-11-2011 09:00 AM)simonc Wrote:  This sounds like a bug in the sync Java actions. We'll get it fixed.

Gregg, who wrote all our Java code to date, has returned to uni so bear with us if it takes a bit longer than normal to address this.

Thanks! I can edit my proxies to correct this temporarily, assuming that I know what the code should be doing. My guess is that I should change:

sync.waitToComplete();
try
{
sync.reportError();
}
catch (ProxyError pe) { }
return sync.getSearchCaps();

to the following:

sync.waitToComplete();
sync.reportError();
return sync.getSearchCaps();

Does this sound OK?

Simon


RE: Error handling for sync invocations in Java - simonc - 28-11-2011 03:51 PM

(28-11-2011 03:44 PM)simoncn Wrote:  Thanks! I can edit my proxies to correct this temporarily, assuming that I know what the code should be doing. My guess is that I should change:

sync.waitToComplete();
try
{
sync.reportError();
}
catch (ProxyError pe) { }
return sync.getSearchCaps();

to the following:

sync.waitToComplete();
sync.reportError();
return sync.getSearchCaps();

Does this sound OK?

That sounds ideal. Would you mind confirming that this does work for you?

The easiest way to test this out will be to edit around line 381 of ohnet/Openhome/Net/T4/Templates/CpUpnpJava.tt

If you're using standard services, then run make CpJava uset4=yes. If you're using custom services you've defined, re-running ohNetGen should have the same effect.


RE: Error handling for sync invocations in Java - simoncn - 29-11-2011 10:48 AM

(28-11-2011 03:51 PM)simonc Wrote:  That sounds ideal. Would you mind confirming that this does work for you?

The easiest way to test this out will be to edit around line 381 of ohnet/Openhome/Net/T4/Templates/CpUpnpJava.tt

If you're using standard services, then run make CpJava uset4=yes. If you're using custom services you've defined, re-running ohNetGen should have the same effect.

There's good news and bad news.

The good news is that I tried this change (actually by hand-editing a single proxy file) and it throws the error back to Java code correctly. I'll have a go at updating the template now.

The bad news is that while testing this by pulling out a network cable on the server, I encountered an ohNet runtime problem. After the cable has been pulled out, if the server updates a property to which the client (now gone) has subscribed, there's a crash in ohNet.dll. I don't think this is Java-related.

Simon


RE: Error handling for sync invocations in Java - simonc - 29-11-2011 01:10 PM

(29-11-2011 10:48 AM)simoncn Wrote:  There's good news and bad news.

The good news is that I tried this change (actually by hand-editing a single proxy file) and it throws the error back to Java code correctly. I'll have a go at updating the template now.

Great. I've modified the template, rebuilt and committed locally. The changes should make it to github this evening.

(29-11-2011 10:48 AM)simoncn Wrote:  The bad news is that while testing this by pulling out a network cable on the server, I encountered an ohNet runtime problem. After the cable has been pulled out, if the server updates a property to which the client (now gone) has subscribed, there's a crash in ohNet.dll. I don't think this is Java-related.

This sounds very much like a bug I fixed on Friday. If you didn't update your ohNet source yesterday can you do so now and try again please? If you still see a problem, posting the native call stack at the point of the crash would be very helpful.


RE: Error handling for sync invocations in Java - simoncn - 30-11-2011 05:02 PM

(29-11-2011 01:10 PM)simonc Wrote:  This sounds very much like a bug I fixed on Friday. If you didn't update your ohNet source yesterday can you do so now and try again please? If you still see a problem, posting the native call stack at the point of the crash would be very helpful.

I tried the latest code (pulled down today so that I would get the proxy change as well) and I'm sorry to say that the situation is worse than previously. When I pull out the network cable on the server, there's an immediate abort pop-up with a console message:

ERROR: Recursive lock attempted on mutex DMSL from thread ____
Assertion failed. OpenHome/Thread.cpp:89

With the previous level of code (from 1 November), the server continued to run after the cable was pulled out, but failed subsequently when a property was changed.

Simon


RE: Error handling for sync invocations in Java - simonc - 30-11-2011 05:09 PM

(30-11-2011 05:02 PM)simoncn Wrote:  I tried the latest code (pulled down today so that I would get the proxy change as well) and I'm sorry to say that the situation is worse than previously. When I pull out the network cable on the server, there's an immediate abort pop-up with a console message:

ERROR: Recursive lock attempted on mutex DMSL from thread ____
Assertion failed. OpenHome/Thread.cpp:89

With the previous level of code (from 1 November), the server continued to run after the cable was pulled out, but failed subsequently when a property was changed.

Can you provide a stack trace for this please?


RE: Error handling for sync invocations in Java - simoncn - 30-11-2011 05:27 PM

(30-11-2011 05:09 PM)simonc Wrote:  Can you provide a stack trace for this please?

How can I get this? Do I have to launch and debug it using Visual Studio, or is there an easier way?


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

(30-11-2011 05:27 PM)simoncn Wrote:  
(30-11-2011 05:09 PM)simonc Wrote:  Can you provide a stack trace for this please?

How can I get this? Do I have to launch and debug it using Visual Studio, or is there an easier way?

I think I can see the mutex name in your earlier message lets me see the problem here. For future reference though...

The most reliable way to retrieve a stack trace would be to debug it using visual studio. Your abort popup should include an option to launch a debugger at the point of the assertion failure. Once visual studio has launched, select Debug -> Windows -> Call stack for the stack trace.

Its also possible that you'll get a stack trace written to the console if you continue running beyond the initial assertion failed message.