Well, I see a call to getRemoteHost in Cocoon.java but only when debug
is enabled. Is debug enabled in your system?
I also see it used in a few other places such as the session framework,
but there aren't that many. Frankly, if I was trying to troubleshoot
this I'd just use a debugger and set breakpoints at each of the possible
locations and see if anything sticks.
Leonid Geller wrote:
IP->hostname is called reverse DNS lookup.
The slowdown consistently occurs when the client's hostname does not
have an "A" DNS record; having a "PTR" but no "A" record slows things
down even further.
Now, rather than worry about why some clients are set up this way, I
want to make sure the application does not care nor try to resolve the
IP back into a host. Something in Cocoon does that today, either an
InetAddress object or Request.getRemoteHost type call.
A similar issue was captured a while ago here:
http://osdir.com/ml/text.xml.cocoon.user/2002-07/msg01283.html
But in our case, the servlet container (resin) does not make these
requests in a separate test web app. Only cocoon does.
-----Original Message-----
*From:* Joerg Heinicke [mailto:[EMAIL PROTECTED]
*Sent:* Mon 6/4/2007 11:28 PM
*To:* users@cocoon.apache.org
*Cc:*
*Subject:* Re: hostname lookup
On 05.06.2007 02:41, Leonid Geller wrote:
> hostname of the http requestor/client. we have the lookup
disabled in
> apache (2.2.4), so requests handled by the web server or our j2ee
> container/default web app do not experience this problem. we can
tell
> that because 1) they result in access log entries that have client
> ip, not hostname, and 2) they are very fast :)
>
> a request to a cocoon web app results in the client's hostname
logged
> in access log, and if the client is behind a proxy/firewall that
> prevents IP->host resolution, this results in a 15-20 sec response
> delay. subsequent requests from the same client return
> instantaneously, as the dns entry is now cached.
I've never heard of such a "feature" and I'm not aware of a IP->host
resolution, only the other way around. Do you have a stacktrace
when it
fails?
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
