need help with strange java error

Hi Skuba,

 

 

Do you think this is a persistence issue or some other app layer problem? If you want to eliminate persistence as a possible cause, you could try to reproduce the error with just one pool member enabled.

 

 

Do you see a 404 error on the server for log4j.jar? If not, do you see any access log entry for the request?

 

 

Aaron

hi hoolio - thanks for your response

 

 

i'm not sure to be honest. personally, i don't think it's a big ip issue but obviously i've got to investigate just in case. this morning we ran the site on a single server in the pool and still received the same error so i'm pretty sure it's not a persistence issue. having said that, we use standard cookie persistence and i'm wondering if the problem occurs when the cookie session times out?

By definition, session cookies don't time out. The client would stop sending the cookie when the browser is closed and the session cookie in memory is lost.

 

 

If you tested with one pool member and couldn't reproduce the issue, it points to a problem with something other than persistence. Considering it's an application layer error, it's most likely a problem with either the client or the server. Can you try testing direct to the server and eliminate LTM as a possible cause?

 

 

Aaron

when we tested this morning on one server, we still received the error, so i don't think it's persistence related as they got the same error on a single server

 

 

the only thing that confuses me (based on what you said about cookie sessions not expiring) is that when they receive the xml error it kicks them out of the site, and they have to log back in. however, at this point we can see that they're been load balanced on to another member. how is this the case if they're using standard cookie persistence and there's been no time delay and they've not closed their browser?!

 

 

thanks again

Sorry, I meant that if you tested with a single member and the issue still occurred, then it's likely not a persistence issue. The only reason I can think of that LTM wouldn't use the same pool member is either the client doesn't present the cookie, the pool member has been marked down, or a different pool has been selected.

 

 

Do you have an iRule enabled on the VIP? If so, what is it doing? Can you use a browser plugin like HttpFox for Firefox or Fiddler for IE to track what's happening prior to/when the error occurs?

 

 

Can you also check the server logs to see what the server is logging in the access and/or error logs? You said you didn't see anything in the logs, but that seems a bit strange of the client is getting a response from the server.

 

 

Aaron

Do you have an iRule enabled on the VIP? If so, what is it doing? Can you use a browser plugin like HttpFox for Firefox or Fiddler for IE to track what's happening prior to/when the error occurs?

 

 

there's no irule on this vip, just cookie default persistence and no fallback persistence

 

 

Can you also check the server logs to see what the server is logging in the access and/or error logs? You said you didn't see anything in the logs, but that seems a bit strange of the client is getting a response from the server.

 

 

according to our application support team, at the time that the client receives the xml error there is nothing logged on the server

 

 

i'm unsure how to proceed with this one. i've told the business that we could try a different persistence method, but we've been using cookie for years for this particular app so we're obviously reluctant to make any changes

 

 

i'll take a look at the firefox addon

 

 

thanks

hoolio

 

 

i have an interesting update for you...

 

 

turns out, this is related to a bug within various java versions which they still haven't managed to fix. apparently, java suddenly stops referencing the big ip cookie and therefore the connection is reset and the client receives another cookie/session id from big ip causing the application to kick them out!

 

 

see this article from sun... http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6799990

 

 

obviously this doesn't appear to be a problem with big ip itself, but we are reasonably confident that by changing the persistence from cookie to source address the problem will go away

 

 

unfortunately, we actually need to use cookie persistence for users coming from certain subnets. therefore, i need to work on an irule that will identify where a user is coming from and then make a decision whether to use cookie or source address persistence

 

 

if you could offer any input/advice it would be much appreciated

 

 

thanks

 

I'm impressed you were able to track the problem down to such an esoteric bug with Java. Glad you figured it out.

 

 

In addition to the iRule, you could try using cookie insert persistence with a fallback method of source address persistence.

 

 

Aaron