Re: AOL
Martin, > If I go to www.AOL.com I am on their web-server Yup. We're not talking about going to www.aol.com. We're talking about AOL customers browsing this dude's application, which is not hosted through AOL. > and if I check email I am submitting the request thru those same web > servers Huh? > If YOU can guarantee ME that they ARE NOT redirecting then as a way > to handle the special processing for aol you could do something > simple like check the HTTP_REFERER (to identify the requested URL) > You can also interrogate REMOTE_ADDR ~but all bets are off if its a > DHCP address! Again, I think you've got this all backward. There's no conflict with this guy's server IP address. If you are an AOL customer and browse the web (say, to a Tomcat-served webapp), you don't always look like you are coming from the same IP address. > Also as a FYI it would be a good idea to think twice on what you say > about in emails (especially of large corps). I am comfortable with my statements, and understand that these messages last practically forever in the archives. -chris - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AOL
Chris- If I go to www.AOL.com I am on their web-server and if I check email I am submitting the request thru those same web servers If YOU can guarantee ME that they ARE NOT redirecting then as a way to handle the special processing for aol you could do something simple like check the HTTP_REFERER (to identify the requested URL) You can also interrogate REMOTE_ADDR ~but all bets are off if its a DHCP address! Also as a FYI it would be a good idea to think twice on what you say about in emails (especially of large corps).. M- This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents - Original Message - From: "Christopher Schultz" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Tuesday, October 10, 2006 3:27 PM Subject: Re: AOL > Martin, > > Apparently, your mail reader seems my messages as blank (due to poor > handling of GPG attachments). Here is the message I was trying to send: > >> Dude, I think you're totally confused. >> >> You can replace the term "AOL" in all of these messages with "some >> crappy ISP that likes to mix things up by randomly reporting the >> client's IP". >> >> AOL isn't giving anyone anything like 301, 302, or even 200, 'cause it >> ain't the server. > > -chris > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
RE: AOL
Thanks! These are good places to test.
> -Original Message-
> From: Paul Singleton [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 10, 2006 3:06 PM
> To: Tomcat Users List
> Cc: [EMAIL PROTECTED]
> Subject: Re: AOL
>
> Daniel Blumenthal wrote:
> > We just switched from a single server to a cluster, with a load
> > balancer out front to manage incoming connections. The
> load balancer
> > makes the decision to go to app server 1 (app1) or app
> server 2 (app2)
> > based on IP address - once a request comes in from one
> source IP, all
> > future requests (for some period of time) go to the same server.
> >
> > The problem is that it appears that AOL will randomly assign an IP
> > address to every request a user sends.
>
> They presumably run a proxy farm: the IP addresses from
>
>request.getRemoteAddr()
>
> should be those of the (last) proxy which handled the request.
>
> AOL should use the HTTP_X_FORWARDED_FOR* header to convey the
> originating IP address (do they?): you could get this with
>
>request.getHeader("HTTP_X_FORWARDED_FOR")
>
> IMHO if your load balancer switches on RemoteAddr when an
> HTTP_X_FORWARDED_FOR address is available then it is broken,
> and if AOL don't set HTTP_X_FORWARDED_FOR then they are
> guilty of Bad Practice (only those dodgy anonymising services
> have a good reason to do that).
>
> Paul Singleton
>
> * or perhaps HTTP_CLIENT_IP
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org To
> unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AOL
Martin, Apparently, your mail reader seems my messages as blank (due to poor handling of GPG attachments). Here is the message I was trying to send: > Dude, I think you're totally confused. > > You can replace the term "AOL" in all of these messages with "some > crappy ISP that likes to mix things up by randomly reporting the > client's IP". > > AOL isn't giving anyone anything like 301, 302, or even 200, 'cause it > ain't the server. -chris - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AOL
I didnt see your solution so I'll make another suggestion why not trap on HTTP_REFERER ? M- This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents - Original Message - From: "Christopher Schultz" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Tuesday, October 10, 2006 3:08 PM Subject: Re: AOL
Re: AOL
Martin, > Saying you'll only deal with the first n addresses may lead to bigger > problems later on.. I would put a sniffer on to see if AOL is giving > you a 301/302. If that is the case you will have to configure > variables Cache-Control Expires Dude, I think you're totally confused. You can replace the term "AOL" in all of these messages with "some crappy ISP that likes to mix things up by randomly reporting the client's IP". AOL isn't giving anyone anything like 301, 302, or even 200, 'cause it ain't the server. -chris signature.asc Description: OpenPGP digital signature
Re: AOL
Daniel Blumenthal wrote:
We just switched from a single server to a cluster, with a load balancer out
front to manage incoming connections. The load balancer makes the decision
to go to app server 1 (app1) or app server 2 (app2) based on IP address -
once a request comes in from one source IP, all future requests (for some
period of time) go to the same server.
>
The problem is that it appears that AOL will randomly assign an IP address
to every request a user sends.
They presumably run a proxy farm: the IP addresses from
request.getRemoteAddr()
should be those of the (last) proxy which handled the request.
AOL should use the HTTP_X_FORWARDED_FOR* header to convey
the originating IP address (do they?): you could get this with
request.getHeader("HTTP_X_FORWARDED_FOR")
IMHO if your load balancer switches on RemoteAddr when an
HTTP_X_FORWARDED_FOR address is available then it is broken,
and if AOL don't set HTTP_X_FORWARDED_FOR then they are
guilty of Bad Practice (only those dodgy anonymising
services have a good reason to do that).
Paul Singleton
* or perhaps HTTP_CLIENT_IP
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AOL
Dan- Saying you'll only deal with the first n addresses may lead to bigger problems later on.. I would put a sniffer on to see if AOL is giving you a 301/302 If that is the case you will have to configure variables Cache-Control Expires Martin-- This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents - Original Message - From: "Christopher Schultz" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Tuesday, October 10, 2006 12:38 PM Subject: Re: AOL
Re: AOL
Daniel Blumenthal wrote: How does the lb decide where you go for all requests after the first one? Typically, the session id is sniffed from the URL or cookie and the lb maintains a table of mappings that expires after some time. Our two choices are evidently "IP-based" and "cookie-based". Currently, we're using "IP-based", so every IP address is treated as a separate request. I'm looking into making it cookie-based, and making cookies a requirement for the site (currently, we only use cookies to store a couple of simple preferences). Any idea how many people have cookies turned off? Are you *sure* your load balancer isn't capable of recognising session IDs in URLs? If it can, then you have a 3rd option: forget cookies and tell Tomcat to use URL encoding exclusively. Of course, you must call response.encodeURL() anywhere you return a link back into the session, but this is probably good practice anyway, and all cookie-related problems go away (and testing becomes easier: you can have many independent sessions in Firefox tabs etc. :-) Paul Singleton - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AOL
Dan, > Our two choices are evidently "IP-based" and "cookie-based". > Currently, we're using "IP-based", so every IP address is treated as > a separate request. I'm looking into making it cookie-based, and > making cookies a requirement for the site (currently, we only use > cookies to store a couple of simple preferences). Any idea how many > people have cookies turned off? I have no idea, but I always try hard to make it work for just about everyone. My current project even works in lynx. ;) Does the lb have any capabilities to use other hints when the cookie is not available? For example, Tomcat will use ";jsessionid=[A-Z0-9]+" in the URL to identify the session for clients who are not using cookies. > I actually considered [treating AOLers specially], although it seems > a bit of an extreme solution. Yeah, it kinda sucks, especially when you have to have this weirdo config on a separate server (or cluster of servers). > Incidentally, who creates the sessionID? Tomcat creates the session id. > Maybe if I could make sure it only authenticates the sessionID > against the first three numbers in the IP address... I think you're playing with fire, there. Besides, what would you change to make this work, here? -chris signature.asc Description: OpenPGP digital signature
Re: AOL
Daniel Blumenthal wrote: Chris, How does the lb decide where you go for all requests after the first one? Typically, the session id is sniffed from the URL or cookie and the lb maintains a table of mappings that expires after some time. Our two choices are evidently "IP-based" and "cookie-based". Currently, we're using "IP-based", so every IP address is treated as a separate request. I'm looking into making it cookie-based, and making cookies a requirement for the site (currently, we only use cookies to store a couple of simple preferences). Any idea how many people have cookies turned off? Enough that it can be an issue; a couple of years ago we had a survey app where somewhere around 5% of the responses were lost (before we realized what was going on) because of cookies being turned off. However, you might be able to get things to work if you told the users that cookies were required, and allowed them to use the most restrictive cookie settings (same server only, etc). Dave - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AOL
Chris, > How does the lb decide where you go for all requests after > the first one? Typically, the session id is sniffed from the > URL or cookie and the lb maintains a table of mappings that > expires after some time. Our two choices are evidently "IP-based" and "cookie-based". Currently, we're using "IP-based", so every IP address is treated as a separate request. I'm looking into making it cookie-based, and making cookies a requirement for the site (currently, we only use cookies to store a couple of simple preferences). Any idea how many people have cookies turned off? > One option is session sharing (or clustered sessions?). I > have forgotten what they are called but basically all the > servers share session data, so it doesn't matter which server > you eventually go to. If you don't have a lot of data going > into the session, I would imagine that it isn't too chatty on > the backend. > > When consulting for [a large robber baron in the SSL cert > racket], their setup was to actually divert all of their AOL > customers away from the main cluster and onto a separate > machine. I think it was a single-box setup for the AOLers, > based upon the actual load that AOLers represented. I actually considered that, although it seems a bit of an extreme solution. Incidentally, who creates the sessionID? Is it Tomcat? Apache? The browser? Maybe if I could make sure it only authenticates the sessionID against the first three numbers in the IP address... Daniel - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AOL
Dan, > The problem is that it appears that AOL will randomly assign an IP > address to every request a user sends. So a user could end up going > to both servers. Yup. AOL is feisty like that. > The load balancer makes the decision to go to app server 1 (app1) or > app server 2 (app2) based on IP address - once a request comes in > from one source IP, all future requests (for some period of time) go > to the same server. How does the lb decide where you go for all requests after the first one? Typically, the session id is sniffed from the URL or cookie and the lb maintains a table of mappings that expires after some time. It doesn't sound like that's happening here. It looks like your "first time" behavior is actually happening for every request. Can you confirm how your lb works in your setup? > Although this approach seems to work, it also has some problems, and > I was wondering if others had encountered this problem, and if there > was a "standard" solution. One option is session sharing (or clustered sessions?). I have forgotten what they are called but basically all the servers share session data, so it doesn't matter which server you eventually go to. If you don't have a lot of data going into the session, I would imagine that it isn't too chatty on the backend. When consulting for [a large robber baron in the SSL cert racket], their setup was to actually divert all of their AOL customers away from the main cluster and onto a separate machine. I think it was a single-box setup for the AOLers, based upon the actual load that AOLers represented. I would imagine that you could setup session sharing among a cluster of AOL-specific servers if you wanted to do something like that. Then only the AOLers would suffer from the (somewhat) poorer performance you'd get with session sharing. -chris signature.asc Description: OpenPGP digital signature
RE: AOL
Martin, I think there might be a bit of a misunderstanding - America Online (AOL) isn't a server under my control - it's an ISP from which some of my customers come. Daniel > -Original Message- > From: Martin Gainty [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 10, 2006 9:07 AM > To: Tomcat Users List; [EMAIL PROTECTED] > Subject: Re: AOL > > Good Morning Dan- > > It seems you're going thru alot more work because of session > expiration issues Do you know if AOL supports 'sticky' sessions? > > Thanks, > > M- > This e-mail communication and any attachments may contain > confidential and privileged information for the use of the > designated recipients named above. If you are not the > intended recipient, you are hereby notified that you have > received this communication in error and that any review, > disclosure, dissemination, distribution or copying of it or > its contents > - Original Message - > From: "Daniel Blumenthal" <[EMAIL PROTECTED]> > To: "'Tomcat Users List'" > Sent: Tuesday, October 10, 2006 9:00 AM > Subject: RE: AOL > > > > Good morning Martin, > > > > Have I misunderstood? The issue isn't switching from using > Apache as > > a front end (for now), but rather that America Online (AOL) > uses proxy > > banks, so that every request comes in with an arbitrary IP > address. > > This is causing two problems: > > > > 1) Users are logged in on some pages, but not on others, because > > they're being sent to different application servers > > 2) Extra sessions are getting created > > > > I've mostly solved the first problem by using cookies, and > keeping a > > username/hashed password. The second one looks a bit trickier. > > > > As Stefan pointed out: > > > >> The IP is that of the last proxy, which does not have to > be the same > > between requests. > >> But it is almost always from the same range, belonging to > the provider. > > > > The IP addresses are generally of the form A.B.C.xx, where > A, B, and C > > don't change. So ideally there would be a way to allow sessionID > > verification to only check those first three numbers. This > is probably an Apache problem. > > > > Daniel > > > > > >> -Original Message- > >> From: Martin Gainty [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, October 10, 2006 8:37 AM > >> To: Tomcat Users List; [EMAIL PROTECTED] > >> Subject: Re: AOL > >> > >> Good Morning Dan > >> > >> From what I see alot of folks are using Hardware accelerators to > >> overcome inherent delay introduced by front ending with apache To > >> clarify everyone's understanding What does AOL bring to your > >> environment and How does AOL server configure in your environment? > >> If I had to speculate I would suggest a possible misconfig > with one > >> or more of your proxy but I would need to know more of the > >> features/functions that AOL brings > >> > >> Thanks, > >> Martin-- > >> This e-mail communication and any attachments may contain > >> confidential and privileged information for the use of the > designated > >> recipients named above. If you are not the intended recipient, you > >> are hereby notified that you have received this communication in > >> error and that any review, disclosure, dissemination, > distribution or > >> copying of it or its contents > >> - Original Message - > >> From: "Daniel Blumenthal" <[EMAIL PROTECTED]> > >> To: "'Tomcat Users List'" > >> Sent: Tuesday, October 10, 2006 2:12 AM > >> Subject: AOL > >> > >> > >> > We just switched from a single server to a cluster, with a load > >> > balancer out front to manage incoming connections. The > >> load balancer > >> > makes the decision to go to app server 1 (app1) or app > >> server 2 (app2) > >> > based on IP address - once a request comes in from one > >> source IP, all > >> > future requests (for some period of time) go to the same server. > >> > > >> > The problem is that it appears that AOL will randomly > assign an IP > >> > address to every request a user sends. So a user could end > >> up going > >> > to both servers. > >> > > >> > Wit
Re: AOL
Good Morning Dan- It seems you're going thru alot more work because of session expiration issues Do you know if AOL supports 'sticky' sessions? Thanks, M- This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents - Original Message - From: "Daniel Blumenthal" <[EMAIL PROTECTED]> To: "'Tomcat Users List'" Sent: Tuesday, October 10, 2006 9:00 AM Subject: RE: AOL > Good morning Martin, > > Have I misunderstood? The issue isn't switching from using Apache as a > front end (for now), but rather that America Online (AOL) uses proxy banks, > so that every request comes in with an arbitrary IP address. This is > causing two problems: > > 1) Users are logged in on some pages, but not on others, because they're > being sent to different application servers > 2) Extra sessions are getting created > > I've mostly solved the first problem by using cookies, and keeping a > username/hashed password. The second one looks a bit trickier. > > As Stefan pointed out: > >> The IP is that of the last proxy, which does not have to be the same > between requests. >> But it is almost always from the same range, belonging to the provider. > > The IP addresses are generally of the form A.B.C.xx, where A, B, and C don't > change. So ideally there would be a way to allow sessionID verification to > only check those first three numbers. This is probably an Apache problem. > > Daniel > > >> -Original Message- >> From: Martin Gainty [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, October 10, 2006 8:37 AM >> To: Tomcat Users List; [EMAIL PROTECTED] >> Subject: Re: AOL >> >> Good Morning Dan >> >> From what I see alot of folks are using Hardware accelerators >> to overcome inherent delay introduced by front ending with >> apache To clarify everyone's understanding What does AOL >> bring to your environment and How does AOL server configure >> in your environment? >> If I had to speculate I would suggest a possible misconfig >> with one or more of your proxy but I would need to know more >> of the features/functions that AOL brings >> >> Thanks, >> Martin-- >> This e-mail communication and any attachments may contain >> confidential and privileged information for the use of the >> designated recipients named above. If you are not the >> intended recipient, you are hereby notified that you have >> received this communication in error and that any review, >> disclosure, dissemination, distribution or copying of it or >> its contents >> - Original Message - >> From: "Daniel Blumenthal" <[EMAIL PROTECTED]> >> To: "'Tomcat Users List'" >> Sent: Tuesday, October 10, 2006 2:12 AM >> Subject: AOL >> >> >> > We just switched from a single server to a cluster, with a load >> > balancer out front to manage incoming connections. The >> load balancer >> > makes the decision to go to app server 1 (app1) or app >> server 2 (app2) >> > based on IP address - once a request comes in from one >> source IP, all >> > future requests (for some period of time) go to the same server. >> > >> > The problem is that it appears that AOL will randomly assign an IP >> > address to every request a user sends. So a user could end >> up going >> > to both servers. >> > >> > With the exception of user login data, the code is >> reentrant, but I've >> > had to store login information as cookies (max age = -1 so only for >> > the current >> > session) so that the user will automatically log in to the other >> > server if/when they hit it. Although this approach seems >> to work, it >> > also has some problems, and I was wondering if others had >> encountered >> > this problem, and if there was a "standard" solution. >> > >> > >> > >> > >> > > > > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
RE: AOL
Good morning Martin, Have I misunderstood? The issue isn't switching from using Apache as a front end (for now), but rather that America Online (AOL) uses proxy banks, so that every request comes in with an arbitrary IP address. This is causing two problems: 1) Users are logged in on some pages, but not on others, because they're being sent to different application servers 2) Extra sessions are getting created I've mostly solved the first problem by using cookies, and keeping a username/hashed password. The second one looks a bit trickier. As Stefan pointed out: > The IP is that of the last proxy, which does not have to be the same between requests. > But it is almost always from the same range, belonging to the provider. The IP addresses are generally of the form A.B.C.xx, where A, B, and C don't change. So ideally there would be a way to allow sessionID verification to only check those first three numbers. This is probably an Apache problem. Daniel > -Original Message- > From: Martin Gainty [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 10, 2006 8:37 AM > To: Tomcat Users List; [EMAIL PROTECTED] > Subject: Re: AOL > > Good Morning Dan > > From what I see alot of folks are using Hardware accelerators > to overcome inherent delay introduced by front ending with > apache To clarify everyone's understanding What does AOL > bring to your environment and How does AOL server configure > in your environment? > If I had to speculate I would suggest a possible misconfig > with one or more of your proxy but I would need to know more > of the features/functions that AOL brings > > Thanks, > Martin-- > This e-mail communication and any attachments may contain > confidential and privileged information for the use of the > designated recipients named above. If you are not the > intended recipient, you are hereby notified that you have > received this communication in error and that any review, > disclosure, dissemination, distribution or copying of it or > its contents > - Original Message - > From: "Daniel Blumenthal" <[EMAIL PROTECTED]> > To: "'Tomcat Users List'" > Sent: Tuesday, October 10, 2006 2:12 AM > Subject: AOL > > > > We just switched from a single server to a cluster, with a load > > balancer out front to manage incoming connections. The > load balancer > > makes the decision to go to app server 1 (app1) or app > server 2 (app2) > > based on IP address - once a request comes in from one > source IP, all > > future requests (for some period of time) go to the same server. > > > > The problem is that it appears that AOL will randomly assign an IP > > address to every request a user sends. So a user could end > up going > > to both servers. > > > > With the exception of user login data, the code is > reentrant, but I've > > had to store login information as cookies (max age = -1 so only for > > the current > > session) so that the user will automatically log in to the other > > server if/when they hit it. Although this approach seems > to work, it > > also has some problems, and I was wondering if others had > encountered > > this problem, and if there was a "standard" solution. > > > > > > > > > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AOL
Good Morning Dan From what I see alot of folks are using Hardware accelerators to overcome inherent delay introduced by front ending with apache To clarify everyone's understanding What does AOL bring to your environment and How does AOL server configure in your environment? If I had to speculate I would suggest a possible misconfig with one or more of your proxy but I would need to know more of the features/functions that AOL brings Thanks, Martin-- This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents - Original Message - From: "Daniel Blumenthal" <[EMAIL PROTECTED]> To: "'Tomcat Users List'" Sent: Tuesday, October 10, 2006 2:12 AM Subject: AOL > We just switched from a single server to a cluster, with a load balancer out > front to manage incoming connections. The load balancer makes the decision > to go to app server 1 (app1) or app server 2 (app2) based on IP address - > once a request comes in from one source IP, all future requests (for some > period of time) go to the same server. > > The problem is that it appears that AOL will randomly assign an IP address > to every request a user sends. So a user could end up going to both > servers. > > With the exception of user login data, the code is reentrant, but I've had > to store login information as cookies (max age = -1 so only for the current > session) so that the user will automatically log in to the other server > if/when they hit it. Although this approach seems to work, it also has some > problems, and I was wondering if others had encountered this problem, and if > there was a "standard" solution. > > > > >
Re: AOL
Daniel Blumenthal wrote: We just switched from a single server to a cluster, with a load balancer out front to manage incoming connections. The load balancer makes the decision to go to app server 1 (app1) or app server 2 (app2) based on IP address - once a request comes in from one source IP, all future requests (for some period of time) go to the same server. The problem is that it appears that AOL will randomly assign an IP address to every request a user sends. So a user could end up going to both servers. You should configure load balancer to use 'sticky sessions' (mod_jk and mod_proxy_ajp does it). -- Mikolaj Rydzewski <[EMAIL PROTECTED]> smime.p7s Description: S/MIME Cryptographic Signature
Re: AOL
The IP is that of the last proxy, which does not have to be the same between requests. But it is almost always from the same range, belonging to the provider. Daniel Blumenthal wrote: > > We just switched from a single server to a cluster, with a load balancer > out > front to manage incoming connections. The load balancer makes the > decision > to go to app server 1 (app1) or app server 2 (app2) based on IP address - > once a request comes in from one source IP, all future requests (for some > period of time) go to the same server. > > The problem is that it appears that AOL will randomly assign an IP address > to every request a user sends. So a user could end up going to both > servers. > > With the exception of user login data, the code is reentrant, but I've had > to store login information as cookies (max age = -1 so only for the > current > session) so that the user will automatically log in to the other server > if/when they hit it. Although this approach seems to work, it also has > some > problems, and I was wondering if others had encountered this problem, and > if > there was a "standard" solution. > > > > > > -- View this message in context: http://www.nabble.com/AOL-tf2414685.html#a6734828 Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
