Hello,
I'm not sure how long ago that was, but I don't live in the Windows
world. I would have thought that someone at Apache Lounge would have
balked if a release was broken. Were you building a release version,
or trunk?
I downloaded a release. This was a few years ago now. I suspect
I haven't looked too closely, but I'm not sure what standard
mechanisms there are to communicate this through a proxy. variables
don't pass through a proxy, and a HEADER is NOT the proper solution here
unless you also implement something similar to the Tomcat RemoteIpValve
where you have
BlueCothe protocol that one can't get away from; that everyone
understands and can easily debug with telnet/etc)at, etc.
Sorry, I think my brain started to fail.
Blue Coat; HTTP is a protocol that everyone understands / can easily
debug with telnet / etc.
Hello,
Anything in particular? Plumbing code is always not terribly pretty.
It's kept up-to-date and generally supports more features than
mod_proxy_ajp.
Well, there was a point where 64bit windows builds didn't even work -
which tells me there's not a lot of testing going on. And having
?
On Fri, Jul 24, 2015, at 09:39 AM, S.Booth wrote:
On 23/07/15 20:38, John Baker wrote:
The flag to which you refer is for AJP only, hence the inconsistency (as
AJP becomes less common and reverse proxying HTTP becomes the norm).
While I agree with you that the http connector should
, Violeta Georgieva wrote:
Hi,
2015-07-23 21:54 GMT+03:00 John Baker jba...@dryfish.org.uk:
Hello,
I note the HTTP connector does the following when
Request.getRemoteUser() is called:
public String getRemoteUser() {
if (userPrincipal == null) {
return
2015 19:42:38 +0100
From: John Baker jba...@dryfish.org.uk
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
Thunderbird/31.5.0
MIME-Version: 1.0
To: users-subscr...@tomcat.apache.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Hello,
I note the HTTP connector does the following when
Request.getRemoteUser() is called:
public String getRemoteUser() {
if (userPrincipal == null) {
return null;
}
return userPrincipal.getName();
}
I understand what it's trying to do but it's not
Hello,
The Tomcat AJP Connector does not support compression. Why has this been
ommitted?
Of course, Apache can do compression but this leaves data running
uncompressed between Apache and Tomcat.
John
-
To unsubscribe,
a quick fix, I was curious to why it hadn't been
done before now?
John
On Fri, 01 Apr 2011 11:20 +0100, Mark Thomas ma...@apache.org wrote:
On 01/04/2011 11:15, John Baker wrote:
Hello,
The Tomcat AJP Connector does not support compression. Why has this been
ommitted?
Because
Hello,
I note there's a GzipOutputFilter in the Tomcat (and JBoss) jar files:
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/coyote/http11/filters/GzipOutputFilter.html
Yet I can't load it in the web.xml file using filter-class. Is there
some pre-defined filter name for this filter?
John Baker jba...@javasystemsolutions.com:
Hello,
I note there's a GzipOutputFilter in the Tomcat (and JBoss) jar files:
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/coyote/http11/filters/GzipOutputFilter.html
Yet I can't load it in the web.xml file using filter-class
Hello,
I've spent a week looking into mod_jk, Apache, etc., and the problem appears to
be due to a bug in the AJP connector within JBoss:
https://jira.jboss.org/browse/JBPAPP-366
This bug is not fixed in the latest release of JBoss 4.2.3, which is rather
disappointing. After downloading the
Thanks for the feedback.
Can you tell me why this if statement exists:
if (poll(fds, 1, timeout) 0)
{
...
}
else
break;
It appears to be at fault.
John
-
To unsubscribe,
On Thursday 09 September 2010 13:59:50 you wrote:
If that doesn't help, it's obvious the Tomcat
doesn't close the socket, so should be investigated
why. Like said before, either the Tomcat doesn't
respond to shutdown or the shutdown's FIN packet
isn't send to the Tomcat or back to
On Thursday 09 September 2010 15:45:44 you wrote:
Nice.
I spoke too soon. I'm now trying to figure out how to print out the IP address
of the socket (I don't really do C) so I can log the socket that caused the
poll to timeout, and compare with a tcpdump.
I would be happy to share all my evidence and write a report once we get to the
bottom of this problem.
Any hints on printing out the socket IP (i.e. of Tomcat)?
On Thursday 09 September 2010 15:47:33 you wrote:
On 09/09/2010 03:22 PM, John Baker wrote:
Do you fancy putting that change
Interestingly, some of our JBoss instances are showing a large number ajp
threads that seem to be in keep alive mode but are well beyond the
connectionTimeout defined in server.xml (which is set to 9):
Max threads: 40 Current thread count: 40 Current thread busy: 40
Max processing time:
On Thursday 09 September 2010 16:08:04 you wrote:
On 09/09/2010 04:48 PM, John Baker wrote:
On Thursday 09 September 2010 15:45:44 you wrote:
Nice.
I spoke too soon. I'm now trying to figure out how to print out the IP
address of the socket (I don't really do C) so I can log
Hello
We've just noticed that the maintenance mode operates on all workers, so
having one worker run maintenance for the rest is making tracing the
problem difficult. Reading down the logs, we can see it finds a worker
and iterates through workers perforing maintenance.
Is this correct?
Moving
Hello,
I don't thikn the shutdown call is to blame - I think it's the large pile
of code below. i.e. everything below the if (shutdown(..)) below. The
question is, what does it all do and does it actually work? It appears to
be the 'drain' code, but given it often results in this message:
On 09/08/2010 05:08 PM, John Baker wrote:
The code *is* required.
It is used when the client disconnects while the backend
still has some data in the AJP buffer. Drain is needed
to read that excess data.
Why does it always report 0 bytes read?
If you can compile mod_jk and test, try
--
From: John Baker
To: Tomcat Users List
ReplyTo: Tomcat Users List
Subject: Re: 2 second delays in mod_jk while maintaining workers
Sent: 8 Sep 2010 16:41
On 09/08/2010 05:08 PM, John Baker wrote:
The code *is* required.
It is used when the client disconnects while the backend
still has some
Looks like your application took too long to respond and by the time it tried
to write to the output stream, it had been closed. Have you set any
connection/socket timeouts?
-Original Message-
From: Sumeet Chitte chittesum...@gmail.com
Date: Wed, 8 Sep 2010 21:48:31
To:
I thought an illegal state exception would occur if an attempt was made to
write to a socket that's now shut but you are right, it looks more like an
attempt to perform an internal redirect after response has been committed
(although that message should appear in the logs).
-Original
On Tuesday 07 September 2010 06:28:33 you wrote:
On 09/06/2010 11:59 PM, John Baker wrote:
What's jk_maintain?
Function that maintains the workers
(closes excess connections inactive for a long time)
Anyhow, like Rainer said, if that's the case
you should have something like
On Tuesday 07 September 2010 08:59:27 you wrote:
It means that socket shutdown failed.
Do you have firewall between mod_jk and JBoss or some non-standard
network driver (e.g running under some VM)?
We are using VMs but there should be no firewall. I should probably re-iterate
that the
Rainer,
Is this acceptable? I am using a tail and an egrep to match the various
statements you wish to see. if it's missing anything, plesae let me know what
to add to the grep.
[Tue Sep 07 10:20:20.617 2010] [18806:46962404156768] [debug]
find_match::jk_uri_worker_map.c (850): Attempting
TM,
On Tuesday 07 September 2010 09:47:17 you wrote:
If you have enough resources, try to disable
connectionTimeout on AJP connector and see weather
the same will happen again.
I've removed the connectionTimeout attribute and the problem persists - I can
see the lingering bytes in 2 sec
Rainer,
On Tuesday 07 September 2010 11:09:46 you wrote:
[Tue Sep 07 10:20:20.617 2010] [18806:46962404156768] [debug]
find_match::jk_uri_worker_map.c (850): Attempting to map context URI
'/*=lb-jboss51-integration' source 'JkMount'
[Tue Sep 07 10:20:20.617 2010] [18806:46962404156768]
On Tuesday 07 September 2010 11:13:07 you wrote:
It's obvious that
shutdown(socket, SHUT_WR)
poll(socket, 2 seconds)
close(socket)
caused poll call to time out, meaning that
the JBoss side didn't respond to the
shutdown(socket, SHUT_WR) call by
closing it's side of the connection.
Rainer,
On Tuesday 07 September 2010 11:09:46 you wrote:
I don't like socket_timeout ...
worker.basic.socket_timeout=90
but I would like socket_connect_timeout.
The next two are possibly a bit short, because if the backend e.g. does
a Java Garbage Collection which miht take longer
Where can I find documentation on JkWatchdog?
On Tuesday 07 September 2010 13:51:23 you wrote:
- As a workaround: using a JkWatchdog moves the maintain into a separate
thread. But during the socket closing a lock is held, which blocks other
threads from accessing the same worker.
Hello,
I've discovered what appears to be a bug in mod_jk 1.2.27 and have also
tried 1.2.30 without success. I'm using Apache 2.2.3 (on Redhat EL 5.4).
The problem occurs after previous successful activity and causes a delay
in what looks like socket handling. I noticed bug was resolved in
On Monday 06 September 2010 18:56:20 you wrote:
On 09/06/2010 04:16 PM, John Baker wrote:
I've set the Jk logging to trace and you can see the debug statements and
the 2s delays:
Do you use NFS share by any chance to store the
mod_jk log directory data?
Nope. All log files
On Monday 06 September 2010 22:57:21 you wrote:
I didn't look at the code now, but the 2 seconds remind me of the
connection draining during socket shutdown, which could be related to
jk_maintain?
What's jk_maintain?
-
To
36 matches
Mail list logo
