Bug 19697

Summary: WCF SendTimeout not working in Xamarin
Product: [Mono] Class Libraries Reporter: Jon Goldberger [MSFT] <jon.goldberger>
Component: WCF assembliesAssignee: Bugzilla <bugzilla>
Status: RESOLVED FIXED    
Severity: normal CC: andrewt, atsushi, blake.lee.jones, glenn.wester, joe.isa.pro, lukaszn1111, michael.watson, miguel, mk, mobiledev, mono-bugs+mono, neal
Priority: ---    
Version: unspecified   
Target Milestone: Untriaged   
Hardware: PC   
OS: Windows   
Tags: Is this bug a regression?: ---
Last known good build:

Comment 1 Jon Goldberger [MSFT] 2014-05-12 17:57:17 UTC
Taking reference of article http://docs.xamarin.com/guides/cross-platform/application_fundamentals/web_services/walkthrough_working_with_WCF/ , I am developing one cross platform mobile application.

I have assigned SendTimeout to 10 seconds, but it is not working.
It is working perfectly in my test Web application.

My code is as below

EndpointAddress endPoint = new EndpointAddress("API URL");
BasicHttpBinding binding = new BasicHttpBinding
{
Name = "basicHttpBinding",
MaxBufferSize = 2147483647,
MaxReceivedMessageSize = 2147483647
};
if (endPoint.Uri.Scheme == Uri.UriSchemeHttps)
binding.Security.Mode = BasicHttpSecurityMode.Transport;

TimeSpan timeout = new TimeSpan(0, 0, 10);
binding.SendTimeout = timeout;

I have also checked example project attached with that article. SendTimeout also not working in that too.
Comment 3 Jon Goldberger [MSFT] 2014-05-12 17:58:54 UTC
Version info:

OS Name Microsoft Windows 7 Professional
Version 6.1.7601 Service Pack 1 Build 7601
Other OS Description Not Available
OS Manufacturer Microsoft Corporation
System Manufacturer Hewlett-Packard
System Model HP Compaq Elite 8300 SFF
System Type x64-based PC
Processor Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 3401 Mhz, 4 Core(s), 4 Logical Processor(s)
BIOS Version/Date Hewlett-Packard K01 v02.05, 07-May-2012
SMBIOS Version 2.7
Hardware Abstraction Layer Version = "6.1.7601.17514"


=== Xamarin Studio ===

Version 4.2.3 (build 60)
Installation UUID: d6fd15a3-441b-4057-87d1-bfd6025a3e09
Runtime:
Microsoft .NET 4.0.30319.18444
GTK+ 2.24.22 theme: MS-Windows
GTK# (2.12.0.0)

=== Xamarin.Android ===

Version: 4.12.3 (Business Edition)
Android SDK: C:\Users\nidhi.thakrar\AppData\Local\Android\android-sdk
Supported Android versions:
1.6 (API level 4)
2.1 (API level 7)
2.2 (API level 8)
2.3 (API level 10)
3.1 (API level 12)
3.2 (API level 13)
4.0 (API level 14)
4.0.3 (API level 15)
4.1 (API level 16)
4.2 (API level 17)
4.3 (API level 18)
4.4 (API level 19)
Java SDK: C:\Program Files (x86)\Java\jdk1.6.0_39
java version "1.6.0_39"
Java(TM) SE Runtime Environment (build 1.6.0_39-b04)
Java HotSpot(TM) Client VM (build 20.14-b01, mixed mode, sharing)

=== Build Information ===

Release ID: 402030060
30c4afc300c2a39ec5300851357ce02e49dd217e
Build date: 2014-03-05 16:53:54Z
Xamarin addins: f8a9589b57c2bfab2ccd73c880e7ad81e3ecf044

=== Operating System ===

Windows 6.1.7601.65536 (64-bit)
Comment 4 andrewt 2014-06-19 10:55:17 UTC
I have this issue as well.  I ended up having to revert to using the SOAP client.  I was using PCL profile 136 when I encountered this issue.

It seems that the OperationTimeout in the System.ServiceModel.ClientRuntimeChannel class is not getting defaulted by the SendTimeout from the binding as it should.  The OperationTimeout cannot be set manually due to access modifiers, but it can be seen in the debugger and will always be 60 seconds no matter what you set the SendTimeout to.

http://social.msdn.microsoft.com/Forums/vstudio/en-US/84551e45-19a2-4d0d-bcc0-516a4041943d/explaination-of-different-timeout-types
Comment 5 Mehmet Kartalbas 2014-12-30 02:56:56 UTC
short questin, when will this issue be resolved? I'm waiting since months. For long calculation reason my services need more than 60 seconds until it will answer. I already achieved my goal with workarounds but I would like to delete them after this issue is solved. Please update the status of this bug, this is for some others an important bug. Thanks.
Comment 6 Rolf Bjarne Kvinge [MSFT] 2015-01-05 07:59:03 UTC
*** Bug 25251 has been marked as a duplicate of this bug. ***
Comment 7 Joe Pro 2015-05-07 11:05:20 UTC
I'm also hitting this bug.  I can appreciate the workaround, but would rather be able to set individual timeout values.  In my case, the WCF code is shared across platforms (iOS, Android and windows) and having to use this workaround is a major pain.

This issue has been opened for some time now.  Is it eventually going to be addressed?
Thanks,
Joe.
Comment 8 Neal 2015-05-07 11:07:11 UTC
I was hoping this was resolved in unified and wasn't sure of the status - sad to hear it's NOT fixed.  Miguel & Co. - please fix this ASAP...

Neal
Comment 9 Atsushi Eno 2015-05-21 04:11:36 UTC
fixed in mono master.
https://github.com/mono/mono/commit/35fd7cd2
Comment 10 Miguel de Icaza [MSFT] 2015-05-21 08:27:40 UTC
Thanks Atsushi.

Atsushi also researched a few options that you could attempt as a workaround until we get binaries out:

1) client.ChannelFactory.Endpoint.Binding.SendTimeout =
TimeSpan.FromMilliseconds (1000);
2) client.InnerChannel.OperationTimeout = TimeSpan.FromMilliseconds (1000);
Comment 11 Atsushi Eno 2015-05-21 10:12:01 UTC
Well, actually those options don't work without my fix. You'll have to wait.
Comment 12 Atsushi Eno 2015-05-21 10:15:20 UTC
A workaround is: create a custom Binding with custom BindingElement that you implement a working HTTP stack (HttpRequestChannel) that makes sure to give Timeout value.
Comment 13 Atsushi Eno 2015-05-21 13:24:48 UTC
Actually mobiles have different issue which is caused by Silverlight limitation. 

The latest master removes that #if !NET_2_1 condition.

[master 63a8b86]
Comment 14 lukasz 2015-07-27 11:17:08 UTC
Atsushi Eno 
I assumed, that you have resolved "MONO SendTimeout bug".
Could you tell me how can I install your solution in my mono?
Thank you for your time :)
Comment 15 Rolf Bjarne Kvinge [MSFT] 2016-02-15 16:19:52 UTC
*** Bug 5676 has been marked as a duplicate of this bug. ***