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
