Re: [Mason] Mason-users Digest, Vol 72, Issue 3

[Pedro M. <me...@si...>]

Hi,

On Mon, Jul 23, 2012 at 4:24 AM, A Kobame <kob...@gm...> wrote:
> On Fri, Jul 20, 2012 at 12:45 PM, Pedro Melo <me...@si...> wrote:
>>> Yes, here is an workaround using reverse proxy and run the apps at
>>> separate ports, but this is complicated. And you can't have an common
>>> Session middleware for all apps.
>>
>> Of course you can have a common middleware and a common session
>> between all apps. They don't need to share a process space to have
>> those, just the same configuration for the middlewares. Given that
>> most of them use a cookie to keep track of stuff, and all your apps
>> would share the same hostname, it would just work.
>
> You will run into "race-conditions", and you know this. You know too,
> that all what you wrote is only "workarounds" - not an "clean"
> solution. And if you don't agree, simply check how  Session is
> written, and how it will works when two process want "simpultaneously"
> use the same storage.

huhs? Race conditions will happen no matter how many processes you have over 1.

Even if all your apps are in a single process, if you use Starman or
any other forking/pre-forking solution you can have race conditions.
We mostly ignore the problem because we tend to use the session for
relatively stable stuff, like authentication, so no matter how many ab
-n N your script kiddy client is doing, it would not be a problem.
That and the fact that we keep sessions in Redis with aggressive TTL's
and cleanup of empty sessions.

The fact that you split each app into separate stacks doesn't increase
your race conditions because each regular client is using one tab at a
time.

And yes, splitting each app into a separate stack is a workaround *for
those who want to run them on the same process*. I for one, *like* to
run each app on a separate process, so it's not a workaround *for me*.
Its the way I like to do business.

Having said that, I do hope a future version of Poet allows multiple
apps in the same process space. It opens up a lot of cool use cases,
but I also want that option to be done cleanly, and right now, *I*
don't see a way to do it cleanly. I admit that I'm not terrible
concern about this, so I haven't gave it much though. Usually this
situations get solved when someone has enough motivation to look at
the problem hard and present a solution.


>> Having said that, there are a couple of problems standing in the way
>> of multiple Poet app in the same process. Poet uses singletons in a
>> couple of places and uses the app class name as key for a lot of other
>> stuff. Its also not easy to create a Poet app, with possible several
>> components subclassed, and then subclass that app to fit separate
>> sites.
>
> See, I'm not an Poet "core" developer. I'm trying using Mason2 and porting my
> Mason1 apps. You can disagree, but frameworks are usually created for
> easing users life.

I'm not a core developer either, I just send pull requests for stuff I
find wrong with the code. The fact that I cannot run multiple Poet
apps in the same process is just not wrong enough yet for me to really
look at it.

Maybe someone will come around and find it broken enough to dedicate a
couple of hours to understand all the bits and pieces and suggest a
solution, so far nobody has.


> But I'm enough "good" have many Mason1 apps. Simply, if Poet uses
> "singletons", it is Poet's design problem.

It is a Poet design *choice*.

As a direct replacement for HTML::Mason apps, it can be a problem. For
new Poet-based sites, it simplifies some parts of our life's.

Please understand that I'm also migrating a multi-site HTML::Mason1
app (about 300 .pm's and 200 .html and .mc components) so it's been a
challenge at times. I would love to see a way to subclass Poet apps,
and I believe that work will eventually solve this particular
limitation of Poet. It just hasn't bubbled up enough on my stack to
look into it.


> Don't understand me bad - i'm really very happy that Jon write Mason2
> and Poet. But that not mean than i can't point to basic design flaw -
> the possibility fully use it with PSGI with all BASIC PSGI features.

I do. I just want you to understand that the decision to use a
singleton, and therefore limit the possible use cases for Poet, was
not made in bad faith. I only assume it was made because it fitted the
author use cases at the time, so he kept it as simple as possible for
it to work.

And from what I've read so far this particular decision is still not
important enough for him personally to fix it. I'm sure if someone
appears with a solution he will look at it and eventually accept it
into Poet.


> I hope you agree than Plack is geniue implementation of PSGI and any
> framework should support the BASIC app-mounting. If Poet can't support
> it, because it design - thats mean Poet has design flaws.

Dancer1 had the same problems: single app only. There are workarounds
for it but eventually they redesign the entire system with Dancer2.

I don't believe there will be a need to do this with Poet, but no
voluntary is available at the moment to look at this.

> multiple Poet apps in one Plack. You need this functionality too - i'm
> saying this, based on YOUR older posts here. This is not an urgent
> bug, but it is an importatant enhancement.

I need something different. I need the ability to subclass Poet apps.
The solution for that, subclassing Poet apps, will probably solve your
problem to.

But as a guiding principle, even with HTML::Mason1, I have multiple
processes, one per app.

For some HTML::Mason1 running under mod_perl I even have two separate
apache+mod_perl instances running the same app, to give me graceful
restarts: graceful stop the first instance, start with new code, then
graceful stop the second instance, start it again with new code - no
dropped clients.

Bye,
-- 
Pedro Melo
@pedromelo
http://www.simplicidade.org/
http://about.me/melo
xmpp:me...@si...
mailto:me...@si...