Charles, let's not forget the point in the investigation where the JRun Tech Support department indicated that they were able to reproduce it and called it a bug.
The testing I did took place in a non-proxied environment, with IIS and JRun running on the local machine. The other client was on the same local subnet. I was able to reproduce the problem without leaving the local machine at all by using a version of IE and a version of Netscape to reproduce the problem.) The jsessionid's are temporary browser cookies, not persistent ones. There is no record of them on the user's hard drive because they are only active for the duration of that the browser is open (that's why it is critical to close all instances of the browser between tests, otherwise, the browser would cache them). I don't mean to be difficult, but I don't want the issue to get clouded. Macromedia identified this behavior as a problem with their software. I quote from the email where I asked to not be charged for the tech support incident: "You will not be charged for this incident as we have found a bug." How much more clear can this get? Richard -----Original Message----- From: charles arehart [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 6:55 PM To: JRun-Talk Subject: RE: Attn: Sessions getting mixed up - I'd be worried JRun people! It would be interesting in the testing to also write out or simply compare the value of the cookie used to track the session, to see if a) it's there or b) it's different than it had been in previous invocations of the test. You may find some pattern (which as other posts have suggested could indicate that the browser is stopping the cookie from being sent along with the request). It's important to consider in evaluating this problem: - what cookie is being presented by the browser to the server. That is what will trigger JRun's recognition of the session. - if it's not there, then JRun will do URL rewriting. In that case, it's just doing what it's supposed to, and the culprit would seem to be the browser for not presenting the cookie. - if it's different than it had been previously, then immediately one should look at the cookie stored in the browser (for IE, on a Win2k machine, it's stored in C:\Documents and Settings\<username>\Cookies as something like <username>@<domainname>.txt .... where <username> is the userid the user is logged into on the server and <domainname> is the domain name of the site being browsed. If the cookie stored on the browser isn't the same as the cookie being reported in the JSP/servlet, then something is happening between the browser and Jrun. It could be a proxy (on the client's machine, or on their ISP if dialing in, or in the network in a corporate site), it could be a problem in the web server (if it's stepping in before passing the request to the browser). - if the cookie being reported is different than it had been on a previous execution of the test, but it's indeed the same cookie found within the browser, then one has to think that something caused a new cookie to be sent to the browser (otherwise it wouldn't be different than the previous run). Again, either the web server or JRun could be at fault there. So I'm just suggesting that sorting out this sort of problem involves identifying any of several moving parts. The theories offered by others about IE (and possible its content filtering) seem reasonable. And the fact that you're finding that URL re-writing is "suddenly" taking place is another strong clue. Having a test of the cookie values is the best diagnostic I could think of. As far as the fact that it seems that a cookie or URL sessionid for "someone else's session" is being sent, it would seem valuable then to track WHICH users end up sharing session ids. This would indeed suggest some other potentially strange problem and tracking which are sharing them may provide even further ammunition to diagnose the problem. /charlie -----Original Message----- From: Merdinger, Richard [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 08, 2001 6:59 PM To: JRun-Talk Subject: RE: Attn: Sessions getting mixed up - I'd be worried JRun people! Hi all: This is a result of the app server *assigning* the same jsessionid to two different client requests. These requests can come from different users on different machines using different browser manufacturers. I've done it, I've reproduced it with a FRESH JRun installation with a FRESH JRun server instance with a FRESH application context. There was one file in the web named index.jsp. All it did was to <%= session.getID() %> (pardon the syntax, I'm in a hurry<g>) Both I and a guy in an adjacent cube would 1. Go to the suspect URL 2. compare the session ID's 3. If they were different, we would close the browser completely and repeat. eventually, we would both see the same jsessionid on the screen. The one telltale symptom was that, even though we were using cookies, the url string was rewritten to include the "?jsessionid=" when the problem arose. I gave the tech folks at JRun support the instructions on how to do it and they reproduced it. It was a confirmed bug by the JRun tech folks, and they stated so in an email. What they did about it, I don't know. I would appreciate them telling us, though. --Rich -----Original Message----- From: michael veit [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 08, 2001 11:59 AM To: JRun-Talk Subject: Re: Attn: Sessions getting mixed up - I'd be worried JRun people! I think I see what you mean - since it JRun is just looking for a cookie to decide whether the session is new or not. gotcha. did u see Rich Merdingers post? I think he is saying that Allaire has knows about the bug..I am trying to confirm with him. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
