07-22-2009 01:22 PM
I wrote an app on the BB that consumes a .net web service using JSR172 ( the code for that is generated by a utility from Sun Microsystems ) and it works quite well.
The generated code makes a blocking call until it receives an answer from the web service. This works 99.9 percent of the time but it seems like there is a chance for whatever reason that it can block indefinitely. How can I guard against this? I can spin off another thread to time how long I have been waiting but how do I kill the JSR172 stub call?
The code where it blocks is in javax.microedition.xml.rpc.Operation where it uses the invoke method.
I don't see anyway to make it non-blocking and I wouldn't want to mess with the generated code anyway.
07-22-2009 05:55 PM
Not sure that you would even be able to make that call to the server asynchronous anyway ... since it's using HTTP it really needs to be true "request / response" with the server. I realize it might not be the preferred way of handling this, but I would actually abort the thread that was running the call. Have a timer task check back on the status ... some flag or counter that indicates progress ... and, if it still is blocked on the call to the server abort the thread.
When you think about it this isn't that different then Socket progamming or anything else that blocks while the object that you've called out to decides what to do. If the server wasn't available, or a network connectivity issue came into play, then it would throw an exception anyway.
Food for thought ...
PS: What version of .NET is the web service running on? Also, what did you think of Sun's toolkit ... I'm assuming you used the J2ME Wireless Toolkit??
07-22-2009 09:15 PM
I was thinking of just killing the thread as well, guess the only way to find out if something bad happens is to do it I was mostly worried about leaking memory, but its such a rare occurence that I doubt it will be a problem.
It's a web service written in .net 3.5. The Sun Toolkit works flawlessly, the hardest bit was figuring out how to use it - the documentation is vague to say the least. I also had trouble passing arrays of strings through SOAP with it ( but oddly I could pass far more complicated arrays of my own objects with no problem at all ). I haven't even looked at what else the wireless toolkit can do, I just used the stub generator...
07-22-2009 10:28 PM
To be on the safe side just null everything out ... that way the GC will get its hand on things quicker ... but killing the thread is probably the next best choice short of having something you could call on the Object that would cause it to either stop or throw an exception itself ... thus unblocking the call.
I downloaded, but haven't had time to try the new JWTK v3.0 ... should be interesting.
10-27-2009 06:22 AM
I tried using Stub Generator available in Sun Java(TM) Wireless Toolkit 2.5 for CLDC and entered the following arguments
WSDL FileName or URL: http://localhost/MyWebService
Output Path: C:\Documents and Settings\adam\My Documents
Output Package: MyRMI
CLDC Version: 1.1
It gives the following error.
Stub Generation Failed
error: modeler error: failed to parse decument at "http://localhost/MyWebService": org.xml.sax. SAXParseException: The element type "p" must be terminated by the matching end-tag "</p>".
I guess the STUB generator requires a WSDL file. Now how do I get that in .NET as the .NET web service generates .asmx files.
11-15-2009 11:17 AM
Been having a similar issue with trying to kill a blocking 172 request. I set up another thread using the invokelater() method to check the status and kill the requesting thread but once it sends out a request it just doesn't get killed. I was hoping you could elaborate on your solution for aborting the thread.
08-08-2010 11:30 AM
I offered the suggestion above but I have not actually implemented it ... I have my own proprietary communication channel I built that runs on top of Sockets instead of using slow web services. But keep in mind that ANY communicaiton technique that travels over a network, at its most basic level, is employing Sockets at its foundation so the same basic problems are sharred by both.
This is one of the reasons why it's always considered "bad form" to attempt an operation whereby you have no idea on how long it will take to complete using the main dispatching thread. These operations need to be run asynchronously.
08-10-2010 03:54 AM
If its a .Net based web-service, enter the WSDL FileName or URL as
where Service.asmx is the page of the webservice.