[Mono-dev] Problem in SvcHttpHandler.cs ?

Alan McGovern alan.mcgovern at gmail.com
Tue Jul 6 04:10:49 EDT 2010


The reason why there are no synchronous calls in silverlight is (I  
believe) because you can easily deadlock the plugin by attempting a  
synchronous call when using the browser http stack. For the web  
request to be completed, the browser has to be able to iterate and if  
a plugin is blocking, there's nothing the browser can do.

If I remeber correctly there is an explanation of this on msdn  
somewhere.

Alan

On 6 Jul 2010, at 05:08, Atsushi Eno <atsushieno at veritas-vos-liberabit.com 
 > wrote:

> Hello Thiago,
>
> Thanks, there's a lot of major and minor missing functionalities all
> around. Our class status
> describes large part of those missing stuff (primarily in
> System.ServiceModel.dll):
> http://go-mono.com/status/
>
> Right now we have no plan to build "mono specific" WCF libraries. IMO
> libraries like
> what you said should be released cross platform, at places like  
> codeplex.
> Instead you might have some useful code that could be used in our own
> core WCF
> assemblies (imagine if you have implemented WS-AtomicTransaction aside
> TransactionFlowBindingElement, and we don't have working code now.)
>
> Atsushi Eno
>
> On 2010/07/05 21:27, Thiago Padilha wrote:
>>  Hi Atsushi,
>>
>>  I have started messing with WCF last week but I'm very interested in
>> learning, If you need help with anything just send me a message.
>>  Also, today I'm starting to develop an http binding/channel to allow
>> REST syncronous programming of WCF Services/Clients(compatible with
>> moonlight/silverlight 2/3). I know syncronous service calls aren't
>> officially supported by Silverlight, but(correct me if I'm wrong) I
>> don't see why that should'nt work if I extend at channel level. If  
>> you
>> want to integrate my source code in the Mono specific libraries I'd  
>> be
>> happy to send you.
>>
>> On Fri, Jul 2, 2010 at 3:54 PM, Atsushi Eno
>> <atsushieno at veritas-vos-liberabit.com>  wrote:
>>
>>> Hi,
>>>
>>> Right, thanks for the analysis, that should be fixed, and I have  
>>> an idea.
>>> Though I am now rewriting ASP.NET channel support based on our new  
>>> HTTP
>>> (non-ASP.NET) channel stack and it does not use the code path you  
>>> mentioned,
>>> I'd rather finish the rewrite first and then fix the actual issue.
>>>
>>> The idea above is to use Uri comparison using UriComponents based on
>>> HostNameComparisonMode value (which is ignored so far).
>>>
>>> Atsushi Eno
>>>
>>> On 2010/06/29 21:46, Thiago Padilha wrote:
>>>
>>>>    Hi,
>>>>
>>>>    I'm hosting a WCF service using asp.net/mono from trunk  
>>>> (r159644)
>>>> but encountered a problem when accessing the service from a virtual
>>>> machine :
>>>>
>>>> "
>>>>   The argument HTTP context did not match any of the registered
>>>> listener manager (could be mismatch in URL, method etc.)
>>>> http://172.16.122.2:8080/Person.svc
>>>>
>>>> Description: HTTP 500. Error processing request.
>>>>
>>>> Stack Trace:
>>>>
>>>> System.InvalidOperationException: The argument HTTP context did not
>>>> match any of the registered listener manager (could be mismatch in
>>>> URL, method etc.) http://172.16.122.2:8080/Person.svc
>>>>   at  
>>>> System.ServiceModel.Channels.SvcHttpHandler.FindBestMatchListener
>>>> (System.Web.HttpContext ctx) [0x00120] in
>>>>
>>>> /home/thiago/monotrunk/mcs/class/System.ServiceModel/ 
>>>> System.ServiceModel.Channels/SvcHttpHandler.cs:141
>>>>   at System.ServiceModel.Channels.SvcHttpHandler.ProcessRequest
>>>> (System.Web.HttpContext context) [0x0000d] in
>>>>
>>>> /home/thiago/monotrunk/mcs/class/System.ServiceModel/ 
>>>> System.ServiceModel.Channels/SvcHttpHandler.cs:156
>>>>   at System.Web.HttpApplication+<Pipeline>c__Iterator2.MoveNext ()
>>>> [0x00ce5] in
>>>> /home/thiago/monotrunk/mcs/class/System.Web/System.Web/ 
>>>> HttpApplication.cs:1344
>>>>   at System.Web.HttpApplication.Tick () [0x00000] in
>>>>
>>>> /home/thiago/monotrunk/mcs/class/System.Web/System.Web/ 
>>>> HttpApplication.cs:914
>>>> "
>>>>
>>>>  I think this happened because I tried to access the service trough
>>>> the "172.16.122.0" network which is the virtual network for my VMs.
>>>> The service works well if I access it on the local machine using  
>>>> the
>>>> "http://127.0.0.1:8080/Person.svc" Url, but fails with the same  
>>>> error
>>>> if I use "http://localhost:8080/Person.svc". After looking into the
>>>> source code I think the problem may be on the following  
>>>> conditionals
>>>> (method 'FindBestMatchListener') :
>>>>
>>>> "
>>>> if (l.Uri.Equals (ctx.Request.Url)) {
>>>>                                        best = l;
>>>>                                        break;
>>>>                                }
>>>> //
>>>> if (!ctx.Request.Url.ToString ().StartsWith (l.Uri.ToString (),
>>>> StringComparison.Ordinal))
>>>>                                        continue;
>>>> "
>>>>
>>>> Maybe it should check the Uris for all the network interfaces?(I  
>>>> have
>>>> no idea on how to do that).
>>>> _______________________________________________
>>>> Mono-devel-list mailing list
>>>> Mono-devel-list at lists.ximian.com
>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list


More information about the Mono-devel-list mailing list