locked
Unpredictable MethodAccessException deep in HttpClientHandler RRS feed

  • Question

  • User15741 posted

    I have a very hard to track down occasional error and I would welcome suggestions on likely causes and how to proceed to resolve it.

    I'm getting several errors of the following form:

    System.MethodAccessException: Method `System.Net.WebHeaderCollection:AddValue (string,string)' is inaccessible from method `System.Net.Http.HttpClientHandler/<SendAsync>c__async0:MoveNext ()'
    

    ...and...

    System.MethodAccessException: Method `System.Net.ServicePointManager:CloseConnectionGroup (string)' is inaccessible from method `System.Net.Http.HttpClientHandler:Dispose (bool)'
    

    This appears bogus as both methods are internal and are being accessed legitimately by classes from within their library. My suspicion is that there is some flaw in the logic in AsyncMethodBuilderCore, but it is an area of Mono with which I am unfamiliar.

    It doesn't happen all the time (order of 1% chance) and often goes away if the app is restarted. If it is going to happen, it happens straight away and keeps happening. I get it in Release (standalone) and Debug (shared library) modes equally. It is more likely to happen after an installation, which suggests some sort of library / timing issue.

    I can occasionally trap it in the IDE, but I'm at a loss as how to proceed to debug it. Here is a full stack trace when one of the exceptions was thrown:

    System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<System.Net.Http.HttpClientHandler.<SendAsync>c__async0> (stateMachine={System.Net.Http.HttpClientHandler}) in 
    System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.Net.Http.HttpResponseMessage>.Start<System.Net.Http.HttpClientHandler.<SendAsync>c__async0> (stateMachine={System.Net.Http.HttpClientHandler}) in 
    System.Net.Http.HttpClientHandler.SendAsync (request=, cancellationToken=) in 
    System.Net.Http.HttpMessageInvoker.SendAsync (Parameters=) in 
    System.Net.Http.HttpClient.SendAsyncWorker (Parameters=) in 
    System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<System.Net.Http.HttpClient.<SendAsyncWorker>c__async0> (Parameters=) in 
    System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.Net.Http.HttpResponseMessage>.Start<System.Net.Http.HttpClient.<SendAsyncWorker>c__async0> (Parameters=) in 
    System.Net.Http.HttpClient.SendAsyncWorker (Parameters=) in 
    System.Net.Http.HttpClient.SendAsync (Parameters=) in 
    System.Net.Http.HttpClient.SendAsync (Parameters=) in 
    System.Net.Http.HttpClient.PostAsync (Parameters=) in 
    Log.ReportAsync (Parameters=) in 
    System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<Log.<ReportAsync>c__async0> (Parameters=) in 
    System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.Threading.Tasks.VoidTaskResult>.Start<Log.<ReportAsync>c__async0> (Parameters=) in 
    System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start<Log.<ReportAsync>c__async0> (Parameters=) in 
    Log.ReportAsync (Parameters=) in 
    LearnPad.Droid.Client.LearnPadActionBarActivity.<OnOptionsItemSelected>c__AnonStorey13.OnOptionsItemSelected () in /Users/rupertrawnsley/LearnPad/Source/Mono/LearnPad.Android.Client/View/LearnPadActionBarActivity.cs:260
    System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start<LearnPad.Droid.Client.LearnPadActionBarActivity.<OnOptionsItemSelected>c__AnonStorey13.<OnOptionsItemSelected>c__async2B> (Parameters=) in 
    System.Runtime.CompilerServices.AsyncTaskMethodBuilder<System.Threading.Tasks.VoidTaskResult>.Start<LearnPad.Droid.Client.LearnPadActionBarActivity.<OnOptionsItemSelected>c__AnonStorey13.<OnOptionsItemSelected>c__async2B> (Parameters=) in 
    System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start<LearnPad.Droid.Client.LearnPadActionBarActivity.<OnOptionsItemSelected>c__AnonStorey13.<OnOptionsItemSelected>c__async2B> (Parameters=) in 
    LearnPad.Droid.Client.LearnPadActionBarActivity.OnOptionsItemSelected.AnonymousMethod__2 (Parameters=) in /Users/rupertrawnsley/LearnPad/Source/Mono/LearnPad.Android.Client/View/LearnPadActionBarActivity.cs:258
    System.Threading.Tasks.Task<System.Threading.Tasks.Task>.InnerInvoke (Parameters=) in 
    System.Threading.Tasks.Task.Execute (Parameters=) in 
    System.Threading.Tasks.Task.ExecutionContextCallback (Parameters=) in 
    System.Threading.ExecutionContext.Run (Parameters=) in 
    System.Threading.ExecutionContext.Run (Parameters=) in 
    System.Threading.Tasks.Task.ExecuteWithThreadLocal (Parameters=) in 
    System.Threading.Tasks.Task.ExecuteEntry (Parameters=) in 
    System.Threading.Tasks.Task.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem (Parameters=) in 
    System.Threading.ThreadPool.AnonymousMethod__0 (Parameters=) in 
    

    The code that is throwing the error is as follows:

    ...
                using (var response = await client.PostAsync(new Uri(IoC.Resolve<IPortal>().DevicesUrl, "com/Logs.cfc?method=reportV2"), parameters).ConfigureAwait(false)) {
                    if (response.IsSuccessStatusCode) {
                        Log.Info("Contacted log server successfully");
                    } else {
                        throw new RecoverableException("Failed to send logs: " + response.ReasonPhrase + " (" + await response.Content.ReadAsStringAsync() + ")");
                    }
                    serverResponseData = JObject.Parse(await response.Content.ReadAsStringAsync()); 
                }
    ...
    

    But the errors occur in various places that PostAsync is called.

    The indeterminate nature of the problem makes a simple standalone reproduce very difficult without further clues as to the cause.

    Thursday, July 9, 2015 1:57 PM

All replies

  • User59557 posted

    I had the same issue, it seemed to be fixed with an include;

    private void IncludeServicePointManager() { System.Net.ServicePointManager.EnableDnsRoundRobin = true; }

    Monday, August 10, 2015 12:47 PM
  • User15741 posted

    @ToinedeBoer.8215 Did this work on Windows, because in Mono it doesn't seem to be implemented yet: https://bugzilla.xamarin.com/show_bug.cgi?id=31764

    Monday, August 10, 2015 3:02 PM
  • User59557 posted

    @RupertRawnsley I did it for Android, and it stil seems to work for now.

    Tuesday, August 11, 2015 7:23 AM
  • User15741 posted

    Curious. It should throw an exception according to the code: https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/ServicePointManager.cs#L233

    Tuesday, August 11, 2015 10:25 AM
  • User59557 posted

    Its in the Include, so I will never get invoked for real. (maybe I choose the wrong property to use in include)

    I just wanted to make sure all was included to prevent this: System.MethodAccessException: MethodSystem.Net.ServicePointManager:CloseConnectionGroup (string)' is inaccessible from method `

    I'm still looking into the issue, because it hapend again but much less then before. (when I find something I will let you know)

    Thursday, August 13, 2015 7:20 AM
  • User55558 posted

    I am also starting an investigation on a very similar problem. I get the exception System.MethodAccessException: Method System.Net.WebHeaderCollection:AddValue (string,string)' is inaccessible from methodSystem.Net.Http.HttpClientHandler/c__async0:MoveNext ()' Once I start getting the exception there is no way to work around it, I have to restart my app. I would be very interested in any progress anyone has done on that.

    Friday, August 14, 2015 2:31 PM
  • User38123 posted

    I'm seeing the same crash in HockeyApp for my prod users, 145 crashes in the current release so far... Any progress on solving this?

    md52ce486a14f4bcd95899665e9d932190b.JavaProxyThrowable: System.MethodAccessException: Method System.Net.ServicePointManager:CloseConnectionGroup (string)' is inaccessible from methodSystem.Net.Http.HttpClientHandler:Dispose (bool)'

    at System.Net.Http.HttpMessageHandler.Dispose () [0x00000] in :0 at System.Net.Http.DelegatingHandler.Dispose (Boolean disposing) [0x00000] in :0 at System.Net.Http.HttpMessageHandler.Dispose () [0x00000] in :0 at System.Net.Http.DelegatingHandler.Dispose (Boolean disposing) [0x00000] in :0 at System.Net.Http.HttpMessageHandler.Dispose () [0x00000] in :0 at System.Net.Http.DelegatingHandler.Dispose (Boolean disposing) [0x00000] in :0 at System.Net.Http.HttpMessageHandler.Dispose () [0x00000] in :0 at System.Net.Http.HttpMessageInvoker.Dispose (Boolean disposing) [0x00000] in :0 at System.Net.Http.HttpClient.Dispose (Boolean disposing) [0x00000] in :0 at System.Net.Http.HttpMessageInvoker.Dispose () [0x00000] in :0 at RPR.Mobile.Shared.Http.WebApiHttpClient.RPR.Mobile.Shared.Contracts.IWebApiHttpClient.Dispose () [0x00000] in :0 at RPR.Mobile.Shared.Services.BaseDataService+c__AnonStorey12[RPR.Mobile.Shared.Entities.Common.Http.EmptyBody,RPR.Mobile.Shared.Entities.Common.Http.EmptyBody].<>m__1 (System.Threading.Tasks.Task1 a) [0x00000] in :0 at System.Threading.Tasks.ContinuationResultTaskFromResultTask2[RPR.Mobile.Shared.Entities.Common.Http.QueryResponse1[RPR.Mobile.Shared.Entities.Common.Http.EmptyBody],RPR.Mobile.Shared.Entities.Common.Http.EmptyBody].InnerInvoke () [0x00000] in :0 at System.Threading.Tasks.Task.Execute () [0x00000] in :0 at dalvik.system.NativeStart.run(Native Method)

    Monday, August 31, 2015 6:38 PM
  • User209 posted

    I really recommend using the ModernHttpClient handler. So much more reliable. Also couple it with Polly for retry logic.

    Monday, August 31, 2015 6:57 PM
  • User15741 posted

    @Cheesebaron I've now switched to ModernHttpClient and I get the same problem. It must be happening outside of the MessageHandler code.

    Thursday, October 1, 2015 1:51 PM
  • User209 posted

    At the outer level, how are you invoking your task?

    Thursday, October 1, 2015 7:10 PM
  • User15741 posted

    @Cheesebaron Usually something like this:

    var url = new Uri("http://google.com");
    var formParameters = new Dictionary<string, string>() {
        { "paramA", "valueA" },
        { "paramB", "valueB" },
    };
    var content = new FormUrlEncodedContent(formParameters);
    using (var httpClient = new HttpClient(new ModernHttpClient.NativeMessageHandler()))
    using (var response = await httpClient.PostAsync(url, content).ConfigureAwait(false)) {
        if (response.IsSuccessStatusCode) {
            // Process response
        }
    }
    

    We have always created a new HttpClient because until recently there was a threading bug in Mono that stopped you reusing the same client. I've actually switched to a shared instance of HttpClient now for most requests in case it gets around this bug somehow.

    Friday, October 2, 2015 8:32 AM
  • User209 posted

    So where would this code go usually? In an event handler? Maybe something else?

    I can't say that I've ever seen these issues in my apps. I usually invoke that kind of code from ICommand implementations in my ViewModel, which in turn calls a Service, which is basically a singleton helper class, which does all the heavy lifting.

    Friday, October 2, 2015 9:38 AM
  • User15741 posted

    Yes, typically some sort of event handler would initiate the call (onRefresh for instance), often on the UI thread, but obviously context will have switched to a background thread (using async/await) by the time the HTTP code executes.

    I don't use a particular view model component, but the structure is similar to what you describe: almost all HTTP requests are channeled through a small number of singleton functions that abstract away the complexities of the request and merely return the requested resource.

    In case it's relevant: I forgot to mention in my example that I always set the Timeout property of the HttpClient to avoid an indefinite hang when making the request.

    I don't think I'm doing anything particularly unusual, although my app does can download tens of resources at once over a short space of time. The fact that this problem is not experienced by many other users is surprising and probably relevant.

    It smells like a threading problem deep in the async/await marshalling code. It must cause some sort of stateful corruption because once it happens, it continues to happen with every request.

    Friday, October 2, 2015 9:56 AM
  • User38123 posted

    I'd agree that you're probably not doing something unusual, as we're seeing the same issue still and are using ModernHttpClient as well. I double-checked and everywhere we instantiate a HttpClient we're passing in a ModernHttpClient handler.

    Friday, October 2, 2015 4:37 PM
  • User12817 posted

    Hi @RupertRawnsley and @JustinToth

    Do either of you have a method of reproducing this? As mentioned by Rupert, this issue seems to happen very seldom and goes away after a fresh instance.

    Ideally we'd be interested in a way to replicate this(Even if it's rare) with a sample project so that we can officially get this reported in our Bugzilla tracking tool. That way one of our platform engineers can investigate this further.

    If either of you have a method of reproducing this in a sample repository, please feel free to reply to this forum post or start a bug report. I will personally move forward with a bug report once I can find a means of reproducing this.

    Thanks!

    Tuesday, December 1, 2015 8:45 PM
  • User15741 posted

    Hi @JonDouglas,

    Thanks for looking at this one. I'm afraid I haven't found a reliable reproduce for it yet, but I will certainly share it if I do.

    There is a slim possibility it is related to this other rare bug for which I think I have found a reproduce. They are both deep in the heart of the HTTP code and manage to corrupt the stack irrevocably. Perhaps they are different presentations of a problem with a common cause?

    Tuesday, December 1, 2015 9:17 PM
  • User118061 posted

    Having the same issue once a week. Any ideas on how to solve the issue ?

    Polly could be an option, but once we get the exception, even 3 retry attempts will not fix the issue :(

    Wednesday, February 10, 2016 8:59 AM
  • User9885 posted

    I am having the same issue :/

    Thursday, February 11, 2016 12:11 PM
  • User13348 posted

    Having the same issue ;(

    Monday, February 22, 2016 8:37 PM
  • User150488 posted

    I am having the same issue. With android, I do something like: call a webservice -> timeout (in 30s) -> kill app -> launch again -> and i meet this issue When i get this issue, i can't call any webservice, must re-install app to do that.

    Hope we can get it done as soon as!!

                        var requestMsg = requestMsgFunc();
                        Debug.WriteLine("Real API: " + requestMsg.RequestUri);
    
                        var response = await Task.Run(() =>
                        {
                            var cancelSource = new CancellationTokenSource();
                            var reqTask = httpClient.SendAsync(requestMsg, cancelSource.Token);
                            if (Task.WaitAny(new Task[] {reqTask}, TimeSpan.FromSeconds(TIME_OUT_IN_SECOND)) < 0)
                            {
                                cancelSource.Cancel(); // attempt to cancel the HTTP request
                                throw new NetworkException();
                            }
                            return reqTask.GetAwaiter().GetResult();
                        }).ConfigureAwait(false);
    
                        var responseString = await response.Content.ReadAsStringAsync();
                        requestMsg.Dispose();
    
    Wednesday, February 24, 2016 9:09 AM
  • User92384 posted
    Error: System.MethodAccessException: Method `System.Net.ServicePointManager:CloseConnectionGroup (string)' is inaccessible from method `System.Net.Http.HttpClientHandler:Dispose (bool)'
    
    at System.Net.Http.HttpMessageHandler.Dispose () [0x00000] in :0 
    at System.Net.Http.HttpMessageInvoker.Dispose (Boolean disposing) [0x0001c] in :0 
    at System.Net.Http.HttpClient.Dispose (Boolean disposing) [0x00023] in :0 
    at System.Net.Http.HttpMessageInvoker.Dispose () [0x00000] in :0 
    at Microsoft.IdentityModel.Clients.ActiveDirectory.HttpClientWrapper+d__1.MoveNext () [0x0045e] in :0 
    --- End of stack trace from previous location where exception was thrown ---
    

    That's quite annoying. I have to choose not to call dispose. But what I can I do for ADAL lib?

    Tuesday, March 8, 2016 3:14 AM
  • User139075 posted

    @RupertRawnsley Did you find the solution to this issue? Could you mind sharing it here?

    Friday, April 1, 2016 7:26 PM
  • User15741 posted

    @WingChan.5109 Sorry, nothing yet. I've failed to find a simple and reliable reproduce to submit to Xamarin.

    Friday, April 1, 2016 9:03 PM
  • User179785 posted

    JavaProxyThrowable: System.MethodAccessException: Method System.Net.WebHeaderCollection:AddValue (string,string)' is inaccessible from methodSystem.Net.Http.HttpClientHandler/c__async0:MoveNext ()'

    I'm my case this exception is caused by the network switching connections, for example going from 3G to Wi-Fi during an IO request.

    Sunday, May 1, 2016 3:29 AM
  • User92384 posted

    Error happens in ADAL,

    OS version: Lollipop Device: samsung SM-A300H

    Error: System.MethodAccessException: Method System.Net.ServicePointManager:CloseConnectionGroup (string)' is inaccessible from methodSystem.Net.Http.HttpClientHandler:Dispose (bool)'

    at System.Net.Http.HttpMessageHandler.Dispose () [0x00000] in :0 at System.Net.Http.HttpMessageInvoker.Dispose (Boolean disposing) [0x0001c] in :0 at System.Net.Http.HttpClient.Dispose (Boolean disposing) [0x00023] in :0 at System.Net.Http.HttpMessageInvoker.Dispose () [0x00000] in :0 at Microsoft.IdentityModel.Clients.ActiveDirectory.HttpClientWrapper+d__1.MoveNext () [0x0045e] in :0

    Here are some devices have the problem: Android version: JellyBeanMr1 Device: Sony C2305 OS version: LollipopMr1 Device: samsung SM-J110M Android version: Lollipop Device: samsung SM-T805Y OS version: Kitkat Device: samsung GT-I9060I Android version: Lollipop Device: samsung SM-A500G Android version: M Device: motorola XT1068 Android version: Kitkat Device: Xiaomi HM NOTE 1S

    Tuesday, May 3, 2016 11:13 PM
  • User80805 posted

    Hello to everybody, we also came across this problem (1% of our clients).

    System.MethodAccessExceptionMethod System.Net.WebHeaderCollection: AddValue (string, string) 'is inaccessible method from System.Net.Http.HttpClientHandler / c_async0: MoveNext ()' raw System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start (ref TStateMachine Statemachine) System.Runtime.CompilerServices.AsyncTaskMethodBuilder .start (ref TStateMachine Statemachine) System.Net.Http.HttpClientHandler.SendAsync (HttpRequestMessage request, CancellationToken cancellationToken) System.Net.Http.HttpMessageInvoker.SendAsync (HttpRequestMessage request, CancellationToken cancellationToken) System.Net.Http.HttpClient. _ BaseCallProxy0 (HttpRequestMessage request, CancellationToken cancellationToken) System.Net.Http.HttpClient.SendAsyncWorker ()

    We already created a bug in Bugzilla Xamarin on this issue.

    https://bugzilla.xamarin.com/show_bug.cgi?id=41133

    When I look at the date of forum posts, it is quite sad that there is such a serious problem in one of most important part of today's applications which is the communication with the web. The worst part of it all is, that there is no way to make it functioning again, except of restarting the application. It is even worse, because even creating new HttpClient does not help there. So how we tell user, that he must restart an application/phone to let it function again? Many users even do not know, how to restart an app (they only know how to switch/minimize it).

    If it was an issue in our code, I would definitely reserve maximum possible number of people for solving it. Unfortunately, we do not see another way to solve the problem except of code analysis. However, we are not much of help for searching through your code, with our team size of 3 programmers. As well as others, we do not have much chance to find out when the problem starts to occure.

    I could not help, but the situation comes to me so, that Xamarin company is waiting until someone brings a problem on a silver platter and sends a test project. There is so much possitive energy during presenting new features everywhere and you are not able able to fix the problem in such an important part as HttpClient?

    We are using your products for a long time and appreciate a work you do. However, I apologize for criticism, but in this case you simply deserve it.

    Tuesday, May 17, 2016 3:17 PM
  • User38123 posted

    ^ What he said...

    Thursday, May 19, 2016 4:05 PM
  • User2378 posted

    Same issue - Added to your bug report.

    Friday, May 27, 2016 3:18 PM
  • User220400 posted

    Clear project, build, deploy. I had old version of dll causing this (with fastdeployment checked).

    Friday, July 22, 2016 4:25 PM
  • User213428 posted

    I've run into this problem a few times, but it happens so rarely for me, so very hard to debug.

    Does this still happen if you use the AndroidClientHandler with HttpClient?

    Thursday, August 11, 2016 5:07 PM
  • User143898 posted

    We never had this problem before, but now it started occuring (at low rate).

    Out of my head, only related thing changed was adding second server connection service that 'could' potentially be called during, or right after first service is complete with server api calls.

    Could someone confirm similar scenario possibility?

    System.MethodAccessException: Method `System.Net.ServicePointManager:CloseConnectionGroup (string)' is inaccessible from method `System.Net.Http.HttpClientHandler:Dispose (bool)'
    
      at System.Net.Http.HttpMessageHandler.Dispose () [0x00000] in /Users/builder/data/lanes/3415/7db2aac3/source/mono/mcs/class/System.Net.Http/System.Net.Http/HttpMessageHandler.cs:38 
      at System.Net.Http.HttpMessageInvoker.Dispose (Boolean disposing) [0x0001c] in /Users/builder/data/lanes/3415/7db2aac3/source/mono/mcs/class/System.Net.Http/System.Net.Http/HttpMessageInvoker.cs:61 
      at System.Net.Http.HttpClient.Dispose (Boolean disposing) [0x00023] in /Users/builder/data/lanes/3415/7db2aac3/source/mono/mcs/class/System.Net.Http/System.Net.Http/HttpClient.cs:121 
      at System.Net.Http.HttpMessageInvoker.Dispose () [0x00000] in /Users/builder/data/lanes/3415/7db2aac3/source/mono/mcs/class/System.Net.Http/System.Net.Http/HttpMessageInvoker.cs:55 
    
    Friday, August 12, 2016 12:57 PM
  • User213428 posted

    @Jurij said: We never had this problem before, but now it started occuring (at low rate).

    Out of my head, only related thing changed was adding second server connection service that 'could' potentially be called during, or right after first service is complete with server api calls.

    Could someone confirm similar scenario possibility?

    This is my observation as well. I can reproduce it sometimes by starting a task with a HttpClient request, and immediately starting another task with another HttpClient request (different HttpClient objects). There could be other problems as well, but this seems to be one of them at least.

    Tuesday, August 16, 2016 2:47 PM
  • User143898 posted

    One question.

    Are you guys using NTLM Authentication aswell?

    For us it seems we hit into couple HttpClient bugs that shouldn't be occuring, and some are not even to be found on reports. NTLM auth might not be widely used in Android, means it gets less feedback.

    Just for example : - we had memory leaks (fixed with patch, once reported), - requests sometimes returning BadRequest for no reason at all (workaround by retry strategy), - DELETE / POST returning NotAuthorized, if sent without content - and couple more, including this one

    Tuesday, August 23, 2016 5:24 AM
  • User15741 posted

    @Jurij not in our case.

    Coincidentally I was trying the new AndroidClientHandler yesterday and got a repeatable BadRequest on one particular resource immediately. You might want to experiment; there's a useful blog post here: http://kerry.lothrop.de/httpclient-flavors/

    Tuesday, August 23, 2016 7:38 AM
  • User143898 posted

    The problem is within the Http client initialization. Bug may occur only within initial requests.

    Multiple requests can potentially build up till Http Client is ready to process them upon internal initialization (then executed at same moment, sometimes causing it to bug internal Http Client state).

    Our current workaround is to let only one request to be sent at start. Once sent, all rest awating requests can be released to run. So far, problem is solved.

    Friday, September 16, 2016 6:13 AM
  • User15741 posted

    @Jurij That's consistent with my experience and a great clue. Do you have an example project you can share? As soon as we get a reproduce I'm sure they will be able to fix it.

    Friday, September 16, 2016 6:55 AM
  • User143898 posted

    @RupertRawnsley

    We are currently busy with Android app release, and there's other projects on side, so we don't have time to reproduce.

    If your working on example project, this might help. Event order, time order, threads.

    Friday, September 16, 2016 7:59 AM
  • User80805 posted

    Hi, we start using AndroidClientHandler after months of waiting. We coul'd confirm that problem dissaper.

    But we have another problems, because there is missing implementaion of Timeout and CancellationToken.

    More info is there

    https://bugzilla.xamarin.com/show_bug.cgi?id=44673

    Hopefully it will help others

    Thursday, October 6, 2016 12:21 PM
  • User38123 posted

    We've gotten 2,000 of these so far in our current release build, and for many releases this has been our highest frequency crash. It's sad that a year and a half later Xamarin still isn't paying attention to this egregious bug.

    Monday, November 28, 2016 4:04 PM
  • User143898 posted

    @JustinToth said: We've gotten 2,000 of these so far in our current release build, and for many releases this has been our highest frequency crash. It's sad that a year and a half later Xamarin still isn't paying attention to this egregious bug.

    You can use workaround from my earlier post above, we haven't had any problems since. And I agree. We have to find bugs in their own source code and find workarounds, meanwhile they leave bugs untouched.

    We aren't even allowed to update our Xamarin version for last few months, just because they still haven't decided to fix newly introduced bugs with newer versions. For example, the SQLite datetime bug which literally corrupts all our collected database data, luckily we found bug before we let it out in wild. Served for them on silverplatter, and yet ignored.

    Saturday, December 17, 2016 1:10 PM
  • User38123 posted

    @Jurij - Thanks for the response! So you're saying that when the app starts up, if multiple http requests are made simultaneously, that's when the issue crops up? It was my understanding that this bug actually happens after many days of the app being open. Can you provide more clarity into that, and also exactly how you fixed it? Are you just ensuring that only one request is executed at a time, and you have some sort of queue that holds any pending ones?

    Saturday, December 17, 2016 1:40 PM
  • User143898 posted

    @JustinToth - If I recall correct, you only have to ensure that first "SendAsync" call blocks any other pending calls. One of the simple ways to do this is with wrapping the call and block the pending requests with TaskCompletionSource bound to the first call completion. But don't forget to handle its CancellationToken properly ;)

    Reasoning behind the workaround is poor internal initialization that happens once for static part of HttpClient per application lifecycle. Long story short, two initial simultaneous requests that triggers internal initialization potentially cause a race condition with slight chance of causing our exception.

    Saturday, December 17, 2016 2:58 PM