Hi, On Mon, Jul 23, 2012 at 4:24 AM, A Kobame <kobam...@gmail.com> wrote: > On Fri, Jul 20, 2012 at 12:45 PM, Pedro Melo <m...@simplicidade.org> 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:m...@simplicidade.org mailto:m...@simplicidade.org ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users
