Forum Discussion
CraigM_17826
Altocumulus
AltocumulusOdd behaviour when pooling to a Tomcat server
Hi all,
we are experiencing an odd issue when traffic which contains specific text is directed to a Tomcat server pool. The URI detection works fine and the tomcat app itself is shown in a iFrame in the browser. The issue we have is that when the Tomcat application redirects back to the main web address it seems that Tomcat intercepts the request and tries to process it and then generates a 404 error. If we wait 10-15 seconds and do a page refresh the page loads from WebSphere. This does work on our current website and the Tomcat app is the same. The only difference I found was that the VIP for the new website being developed did not have a oneconnect profile defined whereas the working site did so I enabled this option. The redirect back from Tomcat now works as it does in our current production system but our developers are now saying other parts of the site are breaking with pages not loading completely so I have had to disable the oneconnect profile. This of course has brought back the Tomcat redirection issue again.
All I can tell you about the tomcat app is what one of our developers told me and thast is when the user clicks on a button to exit the tomcat app, some jsp code to clear the Tomcat session is run and then does an explicit 302 redirect back to a static page on our website.
So, can anyone tell me why oneconnect would have this effect on a redirect from a Tomcat server and if there are any possible ways to achieve the samew thing without using oneconnect profile?
tia
Craig
hoolioCirrostratus
Hi Craig,
This OneConnect wiki page has some good background on the feature:
http://devcentral.f5.com/wiki/default.aspx/AdvDesignConfig/oneconnect.html
I'd guess the issue is with multiple HTTP requests on the same clientside connection which should be sent to separate pools. Without OneConnect, LTM only makes a load balancing decision once per clientside TCP connection. With OneConnect enabled, LTM will evaluate each HTTP request instead. If the second request was going to the wrong pool/pool member, the server might not have a valid session for the request and consequently send a 404.
If you're not using source address translation on the VS, I'd suggest creating a custom OneConnect profile with a 255.255.255.255 source mask and adding that to the VS. This ensures that serverside connections are only reused for the same client IP address. As a result, server logs will accurately reflect the true client IP address. If you are using SNAT on the VS, then it's most efficient to use the default OneConnect profile with a /0 source mask (any serverside connection can be reused for any client IP).
Aaron
CraigM_17826Hi Hoolio,
thanks for your comments. I'll take a look at the OneConnect pages. The VSs do use SNAT and on this test VP, the pools it references (for both WebSphere and Tomcat) only contain one node each. In production there will be 2 or more in each pool though.
To add to this the senior developer has decided to recode their Tomcat app as well, so I'll let them try that first. In the meantime I'll read more about OneConnect.
thanks
Craig- CraigM_17826Hi Hollio (or anyone for that matter!),
We still haven't nutted this out yet. The developers did some code changes on the Tomcat App side they thought may have causing the issue, but no go. There is one other difference the developers picked up which they think could be the issue. On the working environment when the BigIp accesses the tomcat pool a session variable called BigipServer is created and it has a Path of /online , /online being the text we look for in the URI to direct the traffic to the Tomcat server. On the environment that does not work the cookie to the Tomcat pool is created but it's Path is set to /. Is there anyway to set the path, or any ideas on why the path's would be different? I'm not doing anything explicitly to create these pool cookies, I assume it's a function of the BigIp.
tia
Craig - hoolioHi Craig,
Is this a persistence cookie? Is the cookie name BIGipServer< pool name >? If so, I don't think LTM sets the cookie with a path. If you make a curl request for the virtual server, (curl -vk https://1.1.1.1/ or curl -v http://1.1.1.1/) do you see LTM setting the cookie with a path?
I'd expect you'd need to be using an iRule to set the persistence cookie path. If you wanted to do this you could in HTTP_RESPONSE using HTTP::cookie path.
Aaron - hoolioHi Craig,
Regardless of whether this particular issue is related to the persistence cookie or not, it's a best practice to enable a OneConnect profile when using cookie persistence. This allows LTM to parse each HTTP request on a TCP connection and select a different pool or pool member if necessary. See the OneConnect article I posted for details from Deb on this.
Aaron - CraigM_17826Hi Hoolio,
Trouble is when we do this other parts of the site fail to load, I'm dammed if I do and dammed if I don't. I'll fiddle with on of the least used environments to see if I can nut out what's going on. It's hard to test when other people are testing on the same environment.
Regards
Craig - hoolioHave you tried testing with a 255.255.255.255 source mask OneConnect profile? That would limit serverside connection reuse to the same clientside client IP only. A OneConnect profile with any mask ensures that LTM is able to load balancing decision per HTTP request instead of clientside connection.
Aaron