Bug 18376 - Exception being thrown from GetRequestStream() in XA 4.12.00028 (Does not occur in 4.10.02014)
Summary: Exception being thrown from GetRequestStream() in XA 4.12.00028 (Does not occ...
Status: RESOLVED INVALID
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries ()
Version: 4.12.0
Hardware: PC Windows
: Normal normal
Target Milestone: ---
Assignee: Jonathan Pryor
URL:
Depends on:
Blocks:
 
Reported: 2014-03-13 19:36 UTC by Jon Goldberger [MSFT]
Modified: 2014-08-26 18:41 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED INVALID

Comment 1 Jon Goldberger [MSFT] 2014-03-13 19:36:55 UTC
From case: 
We are using Apache Thrift to handle messaging between our Android app and a corporate server. Recently we have noticed intermittent problems with messaging, often on the third request message, although it does sometimes show up in some messaging attempt much later than the third (the first two message attempts have never failed).

Here is the information that we can provide:

* mono-android-4.10.01073_signed.msi – works
* mono-android-4.10.02014.msi – works
* mono-android-4.12.00028.msi – shows the intermittent failures

To test, I have set up a proxy and watch the messages as the requests and responses happen. The failures that I have seen show that the Android device never made any connection, although it goes through the process of waiting for the timeout period before throwing an exception with the message that it couldn’t connect to the server.

The exception we see is being thrown from Thrift.Transport.THttpClient in the SendRequest() method, which is just rethrowing an exception it catches from GetRequestStream()

Here is the original exception, thrown from System.Net.HttpWebRequest.GetRequestStream() :
{System.Net.WebException: The request timed out
at System.Net.HttpWebRequest.GetRequestStream () [0x00000] in <filename unknown>:0
at Thrift.Transport.THttpClient.SendRequest () [0x00020] in c:\Source\access_manager\jac-scanners\Common\ThriftMobile\Transport\THttpClient.cs:165 }

Unfortunately we don’t have any code we can share with you because ours sends its requests to the corporate server, however we can revert to version 4.10.2 and continue developing for now.
Comment 5 Jonathan Pryor 2014-04-22 12:24:57 UTC
There are many many exceptions in the output of Comment #2, e.g.:

> W/WebView ( 5762): java.lang.Throwable: A WebView method was called on thread 'Thread-304'. All WebView methods must be called on the same thread. (Expected Looper Looper (main, tid 1) {428dee20} called on null, FYI main Looper is Looper (main, tid 1) {428dee20})
> W/WebView ( 5762): 	at android.webkit.WebView.checkThread(WebView.java:2063)
> W/WebView ( 5762): 	at android.webkit.WebView.loadUrl(WebView.java:794)
> W/WebView ( 5762): 	at dalvik.system.NativeStart.run(Native Method)

Could the above be at all related?

Furthermore, the WebException reported in Comment #1 reminds me of:

https://bugzilla.novell.com/show_bug.cgi?id=648862#c9

which was a NameResolutionFailure and timeout errors because the HttpWebResponse instance wasn't Dispose()d.

Are we sure that all WebResponses are disposed of?
Comment 6 Daniel 2014-04-22 13:11:25 UTC
I don't believe the WebView exceptions are related - they are all from the UI code, and these continue to happen even with XA 4.10.02014

The communication with our server happens over Apache Thrift.  I checked out their git repository and searched for HttpWebResponse - grep did not find any instance where this was being used explicitly... (I may have not searched their code correctly, but I did double check my work).

The git repository for Apache Thrift is at git://git.apache.org/thrift.git  but perhaps it depends on some other project that does use HttpWebResponse...  I do not know about that.

We do not use HttpWebResponses in any code that we have written.
Comment 7 Jon Goldberger [MSFT] 2014-07-09 19:09:07 UTC
Reopening due to more information having been provided.
Comment 9 Jonathan Pryor 2014-07-24 16:10:33 UTC
Unfortunately, within the last two weeks the test project in Comment #8 has disappeared.
Comment 10 Daniel 2014-07-24 17:30:54 UTC
I have sent another link to the source code to Jon Goldberger via DropBox
Comment 12 Jonathan Pryor 2014-07-24 23:42:03 UTC
@Daniel: Thank you for the test project.

Now, how do I run the repro? If I install the JACScanner project and run the JACScanner app, nothing happens. The process is created and is running -- `adb shell ps` shows the process, and I can see the process creation message in `adb logcat` -- but no UI is shown.

I don't understand how to get the app to the point where it generates the exception.
Comment 13 Daniel 2014-08-01 12:37:47 UTC
That's strange, for us it shows the UI pretty much immediately after starting.   I don't think I have ever seen it not give any UI.

There is a log (sqlite db) that may show what is happening.  It would be in the "Download" directory.  However if it is not drawing the UI, it may not be getting to the point of creating the log either.

I can send you an apk file if you would prefer.
Comment 14 Jonathan Pryor 2014-08-04 08:53:19 UTC
@Daniel: Please provide the .apk.
Comment 15 Daniel 2014-08-04 14:37:17 UTC
@Jonathan:  I just sent you the link a moment ago, let me know if I can do anything else to help
Comment 17 Jon Goldberger [MSFT] 2014-08-04 15:34:54 UTC
@Daniel,

You sent the link to my personal Xamarin email account. I made a private comment above to Jonathan Pryor (Two different Jonathans) with a link he should be able to use to access the files. 

Thanks!
Comment 18 Jonathan Pryor 2014-08-14 18:20:33 UTC
Thank you for the test case. The problem is that your HttpWebRequest code is buggy. (There's an "issue" in our code, but I'm hard pressed to call it a "bug"; let's say it exhibits less than desirable behavior.)

The issue is as follows:

http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.getresponse(v=vs.110).aspx
> You must call the Close method to close the stream and release the connection. Failure to do so may cause your application to run out of connections.

http://msdn.microsoft.com/en-us/library/system.net.webresponse.getresponsestream(v=vs.110).aspx
> The response stream must be closed to avoid running out of system resources. The response stream can be closed by calling Stream::Close or Close

Specifically, Thrift.Transport.THttpClient.SendRequest() calls WebResponse.GetResponseStream():

    source = connection.GetResponse().GetResponseStream();

The problem is that `source` is not reliably or consistently closed; there were code paths that would result in calling GetResponseStream(), and then later creating a *new* request and "overwriting" `source`, thus "losing" the previous value without closing it first.

Fixing the code to ensure that previous values are Close()d before overwriting them removed the timeout exception.

The aforementioned "issue" in our code is that in attempting to fix a Bug #15135, we now internally reuse Sockets, along with various other changes in the HttpWebRequest code. The result of this is that it is now apparently more important to ensure that WebResponse.Close() is invoked, otherwise things are not adequately cleaned up.
Comment 19 Daniel 2014-08-26 18:41:52 UTC
Thanks for your suggestions.

I have implemented them - there is no execution path that does not close the stream, however the symptoms did not change.  (This did not solve the issue.)

Do you have any other suggestions?