Hi, my config is as follows: tomcat 5.5.9 knows two hosts, let's say the host "host1" and the host "host2". http://host1/ is basically a jsp-page echoing the string host1 - http://host2/ echos the string host2. apache 2.0.54 is configured with two vhost with ServerName host1 and host2. Both servers have a ServerAlias too - the one has ServerAlias alias1, the other has ServerAlias alias2 mod-jk 1.2.14 only knows one worker. My worker.properties looks like this: worker.list=worker1 worker.worker1.type=ajp13 worker.worker1.host=127.0.0.1 A very simple config. Both apache vhosts contain a "JkMount *.jsp worker1" Apache's UseCanonialName is on and Tomcats AJP-connector has useIPVHosts turned on. Therefor tomcat will chose the host by the server-name that mod_jk sends. So calling http://alias1/ results in a page containing the string host1, and calling http://alias2/ results in a page containing the string host2. The problem: Sometimes (not always and very selden) http://alias1 returns the string host2 and http://alias2 returns the string host1. I'm not sure, where the problem is, but i'm almost sure it's mod_jk - although i don't know, what should go wrong. I now defined a second worker with the same address and each of apache's vhosts use a different worker. The error didn't come up yet.
Dont know whether related or not. Migrated some old 4.0 serlvet to 4.1 with mod_jk - 1.2.0 After I upgraded mod_jk to 1.2.15 my tomcat-4.1.31 start to point to wrong host. (the serlvet binaries are copied from another host, my point is Previous version did not give me problem) patricko@staff.singnet.com.sg
So the problem still exists with mod_jk 1.2.15 and Tomcat 5.5.12. If two VirtualHosts use the same worker, Tomcat receives the wrong ServerName. IMHO, it has something todo with some cache or some other flaw. (The caches are worker-wise, aren't they?) Does somebody care about this? @Patrick: i don't know if your problem is related. For me, the problem is reproducable, but it does not go wrong always: first HTTP-request works, second doesn't, third works again, some random ...
Patrick, I don't think your problem is related. Try users@tomcat.apache.org for help. Sven, I can't reproduce your problem. If you're still experiencing it and can post the configuration files for Apache, Tomcat, mod_jk, please do.
I'll do my best, to reproduce it with a small testcase.
Created attachment 17404 [details] testcase for the problem i described There are two hosts in tomcat: host1 and host2 They point to /tmp/host1 and /tmp/host2 (which is also in the tgz) There are two hosts in apache: host1/alias1 and host2/alias2 There are two workers defined, but only one is in use from both virtualhosts Put the line "127.0.0.1 host1 host2 alias1 alias2" in /etc/hosts If you run "./test.sh alias1" and "./test.sh alias2" in two terminals you should see only "host1" in one window, and "host2" in the other window. What i experience is, that "./test.sh alias2" output "host1" sometimes - or "./test.sh alias1" outputs "host2". When i change apache's virtualhosts to use two different workers, the problem is gone.
you can also start "./test.sh host1" and "./test.sh host2" with the same strange result: "./test.sh host1" sometimes outputs "host2", and "./test.sh host2" sometimes outputs "host1"
Sven, Both workers on the same port? Why not match the "host" name in workers.properties to the "host" container name in server.xml? Why point both at 127.0.0.1? Seems the proper config is to use names for the workers' host values instead of the same (port and) ip addy in both cases. -Dan
@Dan: i want to use only one worker - and the config attached to this bug only uses one worker - though two are declared. Using two workers that point to the same tomcat is a workaround for me, so that the bug described here doesn't rise. I don't understand, what you mean with "using names" in the worker-file. That doesn't make sense to me since the proper DNS-name would be "localhost" in both cases. The AJP-Connector only listenes on localhost. The names used in the worker-file are _not_ sent to Tomcat by mod_jk, AFAIK.
The comment by Dan sounded much like "your config cannot work at all". So i think i need to explain a little more: The config does work, if you: - restart apache, then run only "./test.sh alias1": you will only see host1 on the console - restart apache, then run only "./test.sh alias2": you will only see host2 on the console - use worker1 for the one virtualhost, and use worker2 for the other, then run "./test.sh alias1" and "./test.sh alias2" in parallel: both scripts return the right results. I hope that you agree with me, that tomcat chooses the hosts like it should. Note, that the server.xml says useIPVHosts="true" - so tomcat does AFAIK not look at the host-header, but at some other information that mod_jk sends. Since i also use "UseCanonicalName On" for apache, mod_jk is supposed to send the ServerName declared for the virtualhost. The config does not work, if you use the same worker for both virtualhosts - which is "the right thing" IMHO since there is also only one tomcat running. What do i mean, with "it does not work" - well: Start "./test.sh alias1" and "./test.sh alias2" in parallel. If you're lucky, it works for 10 requests and you see what you should: "host1" returned by the first command, and "host2" returned by the second command. The result changes for me, and the at least one command "goes crazy" and returns something else: either the command only returns host1 instead of host2 (or vice versa of course) or sometimes i even get an alternating sequence of host1 and host2 by one of the commands - or even by both. Especially the alternating output is a case, that should not occur. The choice made by tomcat is deterministic AFAIK and tomcat is only considering the data that it gets by mod_jk, so how can there be an alternating sequence? My conclusion is, that mod_jk sends the wrong servername, or perhaps sending the servername is optional and tomcat just "reuses" the information it has been given by a former AJP-request on the same connection - but i have no clue about those internal things.
I was not able to reproduce the problem. With your test files and mod_jk from SVN it works OK.
I found the bug. It's still present in Tomcat 6.0.10. I will supply details soon, as well as a patch.
So the bug is in the class org.apache.tomcat.util.buf.MessageBytes. The method setBytes doesn't clear the char-buffer. And the method setChars doesn't clear the byte-buffer. If useIPVHosts is enabled, then the parameter "host" of the org.apache.tomcat.util.http.mapper.map()-method is a MessageBytes-Object of the type T_BYTES. The method MessageBytes.toChars()-method is called. But this method exists, if the charbuffer is already filled. And in deed, the char-buffer is already filled. While the byte-buffer contains the value "host1", the char-buffer may still contain the value "host2" because the MessageBytes objects are reused. And instead of converting the byte-buffer-value "host1" to chars, the old value "host2" is used. This resulted in the bug. So the following patch fixes the problem. With your permission, i would like to clean up the class MessageBytes. It really needs it - IMHO.
Created attachment 19659 [details] patch for this bug The patch should apply cleanly to Tomcat 6.0.10
I discovered, that calling byteC.recycle() also resets the Encoding that might have been set. But actually the setEncoding() method is used nowhere. And calling byteC.reset() doesn't work, because the reset()-method leaves the ByteChunk in an illegal state: the array-pointer is set to null, but the internal "isSet" which controlls the result of isNull() is not reset to false. I'm quite unhappy with the class MessageBytes. For example setInt/setLong also forget to clear the char-buffer. toBytes() ignores the charset. In many cases i discovered strange handeling of non-ASCII characters. So i don't aim to clean it up. There are too many side-effects that might be hurt by any modification.
-1 for the patch. If the problem exists (I really doubt it), a better solution will have to be found.
(In reply to comment #15) > -1 for the patch. If the problem exists (I really doubt it), a better solution > will have to be found. Simply one question: Why? setBytes() invalidates everything - except the value within charC is kept. Anyway: there might be one missing recycle call somewhere. I'm already looking for it.
So in org.apache.coyote.Request.recylce(), this.localNameMB.recycle() is not called. If i add that call, the problem is gone too (my first patch has been reverted before testing). The problem is: remoteAddrMB.recycle(), remoteHostMB.recycle(), localAddrMB.recycle() is also not called. And i have no clue why not or is it should actually be called. Anyway: At least localNameMB gets reused without being recycled. So the internal charC contains an old value. setBytes() doesn't clear internal the charC-cache. toChars() reuses the old value. Hence the bug. I admit, that the semantics of the MessageBytes class are a ridle to me. I don't know, why setBytes() shouldn't invalidate the charC cache (even though it invalidates all other cached values). Somebody please explain the semantics of this class to me! And decide, whether setBytes() should clear charC, or not.
Additional information: the value of localNameMB is set in AjpProcessor.prepareRequest() (line 645) by calling "requestHandlerMessage.getBytes(request.localName())". This getBytes method calls setBytes() of localNameMB. Above that line, remoteAddrMB and remoteHostMB are also set with the same method. And they also might not have been recycled. I don't know for sure.
(In reply to comment #17) > And decide, whether setBytes() should clear charC, or not. It seems you're eager to contribute and stuff, and I think that's good, but if I said -1 to your patch, this means the answer to this question is "no". This will cause problems, and is also inefficient. I think this is a special case with AJP, where recycle should possibly be called on the localName MessageBytes before reading the localName field (it should be fairly explicit that the localName/Addr are otherwise never recycled in the Request object). This is indeed a special case with the IP vhost feature (which IMO is not a very good feature, but it's another story).
Do you understand, why we need to recycle the localName? (short reason: two ajp-requests with different localName over same AJP connection) So i have the feeling, that you want this fix to be AJP specific. I will try to fix it in that way. I tried to fix AjpProcessor/AjpAprProcessor. But the fix only worked, when i did it in JkCoyoteHandler. I simply changed the code from request.recycle(); to request.recycle(); request.localName().recycle(); I don't feel well leaving the other 3 fields (remoteAddr, remoteHost, localAddr) unrecycled. Somehow i feel, like this issue also applies to the other fields. But i don't have enough knowledge to be sure. So i leave this up to you. Now i will attach a new patch. Maybe you like it :-)
Created attachment 19660 [details] new patch
I've committed a more general fix for the JK Connector (i.e. JkCoyoteHandler). I can port it to the APR and AJP Connectors if/when Remy and Mladen doen't veto it.
> I've committed a more general fix for the JK Connector (i.e. > JkCoyoteHandler). I can port it to the APR and AJP Connectors if/when Remy > and Mladen doen't veto it. Thanks a lot! I took a look at your commits. I think, the JK Connector is fixed now. I will test it soon. (At the moment, i don't have much time).
(In reply to comment #23) > I took a look at your commits. I think, the JK Connector is fixed now. I will > test it soon. (At the moment, i don't have much time). I ran my tests, and yes: it's fixed. Sweet!
So William has made a start. His patch works, and could be ported to the other 2 connectors. But i think he's waiting for some reaction by Remy and Mladen. (see comment #22) Let's get this done, so this can be marked fixed.
I think this is as fixed as it's ever going to get (and the connectors have moved on a lot since this was raised).