0001912: sessions and data segmenting

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0001912

[Resin]

minor

always

07-30-07 09:16

08-29-07 16:30

Reporter

ferg

View Status

public

Assigned To

ferg

Priority

normal

Resolution

fixed

Status

closed

Product Version

Summary

0001912: sessions and data segmenting

Description

(rep by Mike Wynholds)

vI 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 a 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.

Additional Information

Attached Files

Relationships

Notes
(0002252) ferg 08-29-07 16:30	server/01n6 The attribute is request.setAttribute("caucho.session-server-id", "app-a"); Or request.setAttribute("caucho.session-server-id", new Integer(0));

Issue History
Date Modified	Username	Field	Change
07-30-07 09:16	ferg	New Issue
08-29-07 16:30	ferg	Note Added: 0002252
08-29-07 16:30	ferg	Assigned To	=> ferg
08-29-07 16:30	ferg	Status	new => closed
08-29-07 16:30	ferg	Resolution	open => fixed
08-29-07 16:30	ferg	Fixed in Version	=> 3.1.3
08-29-07 16:30	ferg	Description Updated

Mantis 1.0.0rc3[^]

29 total queries executed.
25 unique queries executed.