On Aug 29, 2007, at 4:35 PM, Mike Wynholds wrote: > yeah, I think that will be cool. > is there a timeline for 3.1.3 release?
We're on week 5 of 8, so approximately the end of Sept. -- Scott > > ..mike.. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:resin-interest- > [EMAIL PROTECTED] On Behalf Of Scott Ferguson > Sent: Wednesday, August 29, 2007 4:32 PM > To: General Discussion for the Resin application server > Subject: Re: [Resin-interest] Resin / Apache load balancing > withcustomResinserver weighting (for data segmentation purposes) > > > On Aug 29, 2007, at 3:29 PM, Mike Wynholds wrote: > >> i think that I could solve my issue more elegantly with the code >> you are suggesting. it would allow me to essentially keep it ALL >> on the server side, as long as I make sure my session's first hit >> is light, by which I mean not loading up my caches (which is the >> main reason I want to segment the data in the first place). >> >> the project selection can indeed happen before I have a session. >> >> does resin have this capability now, or are you proposing adding it? > > I'm adding it to 3.1.3. The attribute looks like: > > request.setAttribute("caucho.session-server-id", "app-a"); > > Or > > request.setAttribute("caucho.session-server-id", new Integer(0)); > > -- Scott > >> >> ..mike.. >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:resin-interest- >> [EMAIL PROTECTED] On Behalf Of Scott Ferguson >> Sent: Wednesday, August 29, 2007 12:07 PM >> To: General Discussion for the Resin application server >> Subject: Re: [Resin-interest] Resin / Apache load balancing with >> customResinserver weighting (for data segmentation purposes) >> >> >> On Jul 25, 2007, at 9:30 AM, Mike Wynholds wrote: >> >>> well, I did come up with a solution, however it is Resin-specific >>> and requires some client-side code at all login points (ie: there >>> is a customer login implemented in Flex as well as an >>> administrative login implemented in HTML). >>> >>> I set up apache for the web-tier and resin as the app-tier, >>> connected by mod_caucho. I have an idea of the overall systems >>> architecture, but for this discussion we just assume that there is >>> some farm of apache servers that are available under a single URL. >>> >>> Resin offers a way to specify a preferred app-tier server in the >>> cluster by accessing the web-tier and passing in a pre-fab >>> jsessionid, utilizing the Resin-specific algorithm of starting it >>> with an "a", "b", "c", etc. for example, if I wanted the second >>> server listed in the cluster in resin.conf, I request the following: >>> >>> http://www.myserver.com;jsessionid=b >> >> I'm finally getting a chance to look at this. >> >> Does the project selection occur before you have a session? >> >> In other words, would something like the following work? >> >> request.setAttribute("caucho.session-server", "b"); >> >> session = request.getSession(true); >> >> If the session is new, then it will be assigned an ownership of >> server "b", even if that's a totally different machine than the >> current server. The next request will be directed to server "b", >> which will be the same as the pinned data. >> >> -- Scott >> >> >>> >>> now, if there is no current session, mod_caucho will do its best to >>> point the web-tier to the second server in the app-tier cluster. >>> it will still, however, fall back to the other clustered servers if >>> B is down. this is exactly what I want. >>> >>> the downside to this solution is that my client code has to do some >>> work to make this happen. as a user logs in, the client must a) >>> clear the session, and b) figure out the appropriate URL (ie: >>> jsessionid prefix) to use and switcheroo it in as the user logs in, >>> based on the project number entered in to the login form. >>> >>> I actually have a server-side servlet that does the logic, so I >>> just need a way to call it easily. basically, in Flex I just use >>> the standard Flash mx:HTTPService, which is easy, and in HTML I >>> just use AJAX. so it's not too bad, but it would be nice if it was >>> even more "behind the scenes". it can't be 100% behind the scenes, >>> tho. I would at least need a convention of putting the project >>> number in the session or in the login URL under a specific name, or >>> something like that, even if I could do custom load balancing login >>> on a hardware load-balancer. >>> >>> anyway, so far so good. >>> >>> any suggestions for improvements would be definitely appreciated! >>> >>> ..mike.. >>> >>> ..... >>> Michael Wynholds >>> President >>> Carbon Five, Inc. >>> 310 821 7125 x13 >>> [EMAIL PROTECTED] >>> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] [mailto:resin-interest- >>> [EMAIL PROTECTED] On Behalf Of Jay Ballinger >>> Sent: Wednesday, July 25, 2007 8:43 AM >>> To: General Discussion for the Resin application server >>> Subject: Re: [Resin-interest] Resin / Apache load balancing with >>> customResin server weighting (for data segmentation purposes) >>> >>> Mike, >>> >>> This sounds like a perfect use for a hardware load-balancer. A >>> hardware load-balancer can create the affinity for a particular >>> server >>> much like you describe - except for the choosing of a server >>> based on >>> your algorithm, that is. >>> >>> Most hardware solutions implement some sort of persistence feature >>> where, once a load-balancing decision has been made by the >>> device, it >>> will try to persist that same 'user' to that same server for a >>> configurable amount of time. We use this to keep a user's access and >>> application log on one server versus having to hunt around all the >>> servers to piece their session together. >>> >>> If you are trying to create logic that says, "All project 'A' >>> users go >>> on server 'X'," I see that as a big challenge for the chicken-egg >>> scenario you describe - the user already has an affinity to a server >>> before you know the user or the project. However, there are some >>> pretty slick hardware load-balancers out there that can use >>> cookie-driven values. Check out the lineup from F5 - specifically >>> their Big-IP Local Traffic Managers. >>> >>> Of course, you could have a farm of login servers that simply takes >>> the login info and then redirects the user to a different farm of >>> servers based on the project info. >>> >>> Good luck, and let us know what you come up with. >>> >>> + jay >>> >>> On 7/11/07, Mike Wynholds <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>> >>>> >>>> I have a somewhat complex load balancing scenario that I wish to >>>> accomplish. >>>> From my investigation it seems that it's *probably* possible but >>>> I haven't >>>> gotten it to work yet. Here is the scenario: >>>> >>>> >>>> >>>> I have a web app running on Resin 3.1.1 with Apache 2.2 in front >>>> of it. I >>>> want to have multiple Resin servers in a cluster. I may have >>>> multiple >>>> Apache servers as well, but I don't think that's important. If I >>>> do I will >>>> have a hardware load-balancer in front of that. >>>> >>>> >>>> >>>> I want to achieve both failover and server scalability with my >>>> systems >>>> architecture. I think I can utilize a clustering solution to >>>> handle this. >>>> I will need to cluster both Resin sessions as well as a number of >>>> memory/disk caches using the distributed mode of EhCache (or >>>> possible >>>> JBossCache). So far the Resin session clustering is working >>>> fine. However, >>>> for efficiency I really also want to segment my data between >>>> users, in order >>>> to reduce either a) the amount of cache replication (if I use cache >>>> replication) or b) the amount of cache misses (if I use cache >>>> invalidation) >>>> in EhCache. >>>> >>>> >>>> >>>> When people come to the site, they are given a login page >>>> immediately. >>>> There are two entry points: one is HTML-based and one is Flash/ >>>> Flex-based. >>>> Either way the user is prompted to log in with a username, >>>> password and a >>>> project number. I want to pin all users logged in to a particular >>>> project >>>> to the same backend server so that the EhCache can be used as >>>> efficiently as >>>> possible. >>>> >>>> >>>> >>>> But while I say I want to "pin" specific users to specific backend >>>> servers, >>>> I really also want the failover capability built in to load- >>>> balancers. So >>>> what I *really* want is a way to suggest to the load balancer >>>> which server >>>> to prefer, but allow it to fall back in the case of a server being >>>> down. My >>>> algorithm for choosing a server to suggest is simple: I just hash >>>> the >>>> project number, mod by the amount of servers, and choose that >>>> one. Not >>>> smart, but for now that's fine. >>>> >>>> >>>> >>>> I feel like I will want to use the Resin load balancing features >>>> (although I >>>> am open to other suggestions). From the docs it seems like there >>>> may be a >>>> way to do it. I have spent a few hours on this and am not seeing >>>> a very >>>> clear solution. My main theoretical issue is that when the user >>>> hits the >>>> login page a session is created. There is no way to know which >>>> project >>>> number the user will then enter, and therefore which server to try >>>> to pin >>>> him too. But then if he enters a project number, Resin already >>>> has him >>>> pinned to a server by the jssesionid. >>>> >>>> >>>> >>>> Is there a way to tell Resin to keep the session but now house it >>>> on a >>>> different server? >>>> >>>> >>>> >>>> I think the logic of project number à server needs to be in the app >>>> somewhere (ideally the server side, not the Flash side). Can I >>>> set a cookie >>>> or something that can be sniffed by Resin's load balancing >>>> capabilities that >>>> will determine the suggested server to pin to? >>>> >>>> >>>> >>>> I can kind of see the light at the end of the tunnel but haven't >>>> been able >>>> to come up with even a best theoretical approach to this problem. >>>> There is >>>> just too much about Resin load balancing, mod_caucho, hardware load >>>> balancers and the such that I am not intimately familiar with, and >>>> I don't >>>> want to reinvent anything that already exists and works well. >>>> >>>> >>>> >>>> Thanks for any suggestions. >>>> >>>> ..mike.. >>>> >>>> >>>> >>>> ..... >>>> >>>> Michael Wynholds >>>> >>>> President >>>> >>>> Carbon Five, Inc. >>>> >>>> 310 821 7125 x13 >>>> >>>> [EMAIL PROTECTED] >>>> >>>> >>>> _______________________________________________ >>>> resin-interest mailing list >>>> resin-interest@caucho.com >>>> http://maillist.caucho.com/mailman/listinfo/resin-interest >>>> >>>> >>> >>> >>> _______________________________________________ >>> resin-interest mailing list >>> resin-interest@caucho.com >>> http://maillist.caucho.com/mailman/listinfo/resin-interest >>> >>> >>> _______________________________________________ >>> resin-interest mailing list >>> resin-interest@caucho.com >>> http://maillist.caucho.com/mailman/listinfo/resin-interest >> >> >> >> _______________________________________________ >> resin-interest mailing list >> resin-interest@caucho.com >> http://maillist.caucho.com/mailman/listinfo/resin-interest >> >> >> _______________________________________________ >> resin-interest mailing list >> resin-interest@caucho.com >> http://maillist.caucho.com/mailman/listinfo/resin-interest > > > > _______________________________________________ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest > > > _______________________________________________ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest _______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
