[Mono-dev] WCF Fail with System.Net.Sockets.SocketException: Connection reset by peer
Rob Wilkens
robwilkens at gmail.com
Thu Jun 28 12:38:44 UTC 2012
Worth noting, with Combined patch applied (or both other applied
separately), zero unit tests are failing. So apparently, it doesn't
make anything worse, at least as far as tests go.
-Rob
On 06/28/2012 08:20 AM, Rob Wilkens wrote:
>
> Either of the attached patches illustrates what i was trying to say in
> that last patch
>
> (1) attempt2.patch : This attempts to patch just the below concern,
> and is based on a guess.
> -or- (not both)
> (2) combined.patch : This combines attempt2.patch with the patch i
> sent last night since they were on the same branch.
>
> I'm not able to test these anything beyond "does it compile" because i
> don't have sample code to reproduce this with.
>
> -Rob
>
> On 06/28/2012 07:55 AM, Rob Wilkens wrote:
>> Re : The stacktrace below...
>>
>> This occurs when an exception is raised in ChannelDispatcher.cs on
>> line 601. It tries to send back an exception message to the client
>> here, i believe. But when it does that, it uses the existing
>> RequestContext.
>>
>> It's apparent that some data is apparently being sent, such as
>> headers, on the RequestContext (rc) before we get to this exception.
>>
>> If we're dealing with the case of SocketException, which caused us to
>> fail mid-send on the RequestContext, perhaps, again, we shouldn't
>> handle this like every other exception and not reply. i.e. in the
>> exception handler here, if exception is typeof(SocketException) don't
>> reply, what might be more interesting, if this is reproducable, would
>> be to - as debugging - print the exception message and/or stacktrace
>> to the screen to see what exception caused this.
>>
>> Did you file a bug report on this? The discussion on this particular
>> issue (or any particular bug) is probably better stored in the bug
>> report comments than on the whole mailing list. PLus comments like
>> the above would stay in the bug report rather than get lost in the
>> list. IF you file a bug report, post a link to the bug report in
>> this thread (the bug # should be enough).
>>
>> -Rob
>>
>>
>> On 06/27/2012 01:02 PM, shahbour wrote:
>>>
>>>
>>> Hello After more testing between Mac and Windows this is
>>> what i got Crash Windows Mac Linux Without ErroHandler No
>>> Yes Yes With ErrorHandler (return false ) No Yes Yes With
>>> ErrorHandler (return true) No No No Before i was always
>>> returning false in IErrorHandler implementation because i
>>> only implemented for logging purpose but when i return true
>>> for the HandleError , the application fire the error and log
>>> it but never crash. Now i trying to debug the application
>>> under MonoDevelop and repreduce the error, below is what i got
>>>
>>>
>>> System.InvalidOperationException: Cannot be changed
>>> after headers are sent. at
>>> System.Net.HttpListenerResponse.set_ContentType
>>> (System.String value) [0x00027] in
>>> /private/tmp/monobuild/build/BUILD/mono-2.10.9/mcs/class/System/System.Net/HttpListenerResponse.cs:107
>>> at
>>> System.ServiceModel.Channels.Http.HttpStandaloneResponseInfo.set_ContentType
>>> (System.String value) [0x00000] in
>>> /private/tmp/monobuild/build/BUILD/mono-2.10.9/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpContextInfo.cs:274
>>> at
>>> System.ServiceModel.Channels.Http.HttpRequestContext.InternalReply
>>> (System.ServiceModel.Channels.Message msg, TimeSpan
>>> timeout) [0x00046] in
>>> /private/tmp/monobuild/build/BUILD/mono-2.10.9
>>>
>>
>>> /mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:140
>>> at
>>> System.ServiceModel.Channels.Http.HttpRequestContext.Reply
>>> (System.ServiceModel.Channels.Message msg, TimeSpan
>>> timeout) [0x00000] in
>>> /private/tmp/monobuild/build/BUILD/mono-2.10.9/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:101
>>> at
>>> System.ServiceModel.Channels.Http.HttpRequestContext.Reply
>>> (System.ServiceModel.Channels.Message msg) [0x00000] in
>>> /private/tmp/monobuild/build/BUILD/mono-2.10.9/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:96
>>> at
>>> System.ServiceModel.Dispatcher.ListenerLoopManager.ProcessRequest
>>> (IReplyChannel reply,
>>> System.ServiceModel.Channels.RequestContext rc)
>>> [0x0003b] in
>>> /private/tmp/monobuild/build/BUILD/mono-2.10.9/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/ChannelDispatcher.cs:601
>>> at
>>> System.ServiceModel.Dispatcher.ListenerLoopManager.TryReceiveRequestDone
>>> (IAsyncResult result) [0x0001a] in
>>> /private/tmp/monobuild/build/BUILD/mono-2.10.9/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/ChannelDispatcher.cs:575
>>>
>>> Reproducing the error is very simple, just host any application
>>> under console app and in any service function put Thread.Sleep(..)
>>> to give you time to close the browser before it reply. Then call
>>> this function from any client and close it before getting the
>>> response. In my live program i don't put Thread.sleep it is only to
>>> give us time between calling the function and closing the browser.
>>> Under windows we got the bellow that don't crash the application
>>> error.Message "An operation was attempted on a nonexistent network
>>> connection" error.InnerException {"An operation was attempted on a
>>> nonexistent network connection"} System.Exception :q
>>> {System.Net.HttpListenerException} error.ErrorCode 1229 BR Shahbour
>>> ------------------------------------------------------------------------
>>> View this message in context: Re: WCF Fail with
>>> System.Net.Sockets.SocketException: Connection reset by peer
>>> <http://mono.1490590.n4.nabble.com/WCF-Fail-with-System-Net-Sockets-SocketException-Connection-reset-by-peer-tp4650173p4650210.html>
>>> Sent from the Mono - Dev mailing list archive
>>> <http://mono.1490590.n4.nabble.com/Mono-Dev-f1517221.html> at
>>> Nabble.com.
>>>
>>>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120628/5cc40464/attachment-0001.html>
More information about the Mono-devel-list
mailing list