[Mono-dev] Problem in SvcHttpHandler.cs ?
Thiago Padilha
tpadilha84 at gmail.com
Tue Jul 6 06:54:14 EDT 2010
Alan,
I think I read that explanation before, but responsive UI can be
achieved using background threads, so I don't think silverlight should
"force" programmers to use the async pattern.
It seems that the async pattern is forced at the socket level, as
shown in http://msdn.microsoft.com/en-us/library/system.net.sockets.socket_members(v=VS.95).aspx
, so a synchronous WCF stack should probably be implemented at the
transport level.
On Tue, Jul 6, 2010 at 5:10 AM, Alan McGovern <alan.mcgovern at gmail.com> wrote:
> 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