[Mono-aspnet-list] nginx + multiple fastcgi-mono-server4 instance => WebResource.axd 404 error

[Ovidiu Deac]

I don't necessarely need several instances on the same machine but I
certainly need to be able to have more then one instance and do load
balancing over them.

My current approach is to have nginx to handle load balancing between
several fastcgi servers. I haven't been able (yet) to configure nginx to
pass multiple requests to one fastcgi server such that they are processed
in parallel. So I said, no problem, I can have multiple fastcgi servers
configured as an nginx upstream.

The only problem remaining is the fact that resource links are specific to
the application instance which produced them.

Even if I would only use one application instance per machine I will still
need to do load balancing over the machines and thus the problem still
remains.

On Wed, Jan 2, 2013 at 8:10 PM, Jesse Pasichnyk <jesse at pasichnyk.net> wrote:

>  I ran several copies of an app for some time, by copying the physical
> folder several times.  Not the cleanest, but worked fine for me.
>
> Do you really need multiple instances on a box though?  Maybe better to
> scale up each instance to handle more requests?  Is there some hard
> requirement here that can't be worked around with a single instance per box?
>
> Sent from my Windows Phone
>  ------------------------------
> From: Ovidiu Deac <ovidiudeac at gmail.com>
> Sent: 1/2/2013 6:09 AM
> To: Kornél Pál <kornelpal at gmail.com>
> Cc: mono-aspnet-list at lists.ximian.com
> Subject: Re: [Mono-aspnet-list] nginx + multiple fastcgi-mono-server4
> instance => WebResource.axd 404 error
>
>  Thanks for the answer.
>
>  So the short version is that if I want to have multiple instances of the
> application and do load balancing then I must drop mono and use .NET
> instead ?
>
>  Is there any other possibility to achieve load  balancing/high
> availability with mono?
>
> On Wed, Jan 2, 2013 at 3:20 PM, Kornél Pál <kornelpal at gmail.com> wrote:
>
>> Based on the source code of Mono's
>> System.Web.Handlers.AssemblyResourceLoader I think that the implementation
>> is flawed.
>>
>> I am going to describe the problem, but I think that you should file a
>> bug report.
>>
>> Although it is using a hashing algorithm that always results in the same
>> hash for the same script resource, hashes are not generated and stored in
>> the dictionaries unless a link is generated, thus a resource is not
>> available until a link to it was generated by the same AppDomain before.
>>
>> As such even AppDomain restarts can trigger the problem, although a
>> simple refresh on the page fixes it by generating hashes for the web
>> resources that subsequently can be retrieved from the server, provided that
>> there is only one AppDomain (one process, one server) serving the requests.
>>
>> As I see at least the assembly name should be included in the query
>> string, resource hashes can be regenerated based on WebResourceAttributes
>> of the assembly.
>>
>> To prevent loading arbitrary assemblies, the assembly name should be
>> encrypted using the machine key and also should be signed using HMAC to
>> avoid padding oracle vulnerability similar to CVE-2010-3332 that the MS
>> implementation had (encrypted view state, forms authentication cookie, and
>> WebResource.axd were all affected).
>>
>> Kornel
>>
>>
>> On 1/2/2013 12:34 PM, Ovidiu Deac wrote:
>>
>>>  I'm running nginx which does load balancing over several instances of
>>> fastcgi-mono-server4
>>>
>>> Apparently when a webresource link is handled by a different
>>> fastcgi-mono-server than the one which originally produced the link it
>>> returns a 404 error.
>>>
>>> I have set a persistent machinekey as recommended for webfarms but the
>>> problem still remains.
>>>
>>> Any idea what else could be wrong?
>>>
>>> If it makes any difference: the application is written with
>>> F#/WebSharper and we disabled the session state and the forms
>>> authentication.
>>>
>>> Thanks
>>>
>>>
>>>  _______________________________________________
>>> Mono-aspnet-list mailing list
>>> Mono-aspnet-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-aspnet-list/attachments/20130103/d92e6ad1/attachment.html>