> 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 yo
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 mo
> 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
this be raised as a bug?
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
05 PM, Violeta Georgieva wrote:
> Hi,
>
> 2015-07-23 21:54 GMT+03:00 John Baker :
> >
> > Hello,
> >
> > I note the HTTP connector does the following when
> > Request.getRemoteUser() is called:
> >
> > public String getRemoteUser() {
> &g
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 c
:date:from:message-id:mime-version:to:x-sasl-enc:x-sasl-enc; s=
> smtpout; bh=2jmj7l5rSw0yVb/vlWAYkK/YBwk=; b=m27qo6GK9j0GR0sMCdHH
> O6OmEsduURVV7vYF9qFW6KI0koFloRE9xuFsaXV+JpqdHH6eRsMFJGhyR+8X9bqz
> LXHG8age9quYm84NZqPsyHow40pUXbb9qk8ADJB2Vrr4iWSpOJzqsIj16TJQJzJK
>
The AJP connector doesn't support compression (a missing useful feature
in my opinion) so I found myself looking for a filter. Thanks for
letting me know it won't work. I'll look at the example filter.
On Fri, 01 Apr 2011 16:28 +0400, "Konstantin Kolinko"
wrote:
> 201
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 . Is there
some pre-defined filter name for this filter?
John
Given it's 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" wrote:
> On 01/04/2011 11:15, John Baker wrote:
> > Hello,
> >
> > The Tomcat AJP Connector does not support compression. Wh
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, e-mail
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 j
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
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: 5563
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 fan
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.
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
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,
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 Messa
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
Date: Wed, 8 Sep 2010 21:48:31
To:
Reply-To: "Tomcat Users List"
Subject
Original Message------
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 di
> 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 mo
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:
"Shu
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
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.
---
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
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 conne
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:469624041
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,
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
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 prob
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
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
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
> m
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 1.2.3
36 matches
Mail list logo
