Justin Erenkrantz wrote:
On 3/7/06, Jim Jagielski [EMAIL PROTECTED] wrote:
Feh. No way. The argument would hold true if mod_jk
did not provide just the sort of control that you say
we shouldn't provide to users/admins, and control that
*varies* from setup to setup.
Why must we offer
On 3/7/06, Jim Jagielski [EMAIL PROTECTED] wrote:
Feh. No way. The argument would hold true if mod_jk
did not provide just the sort of control that you say
we shouldn't provide to users/admins, and control that
*varies* from setup to setup.
Why must we offer a shiny knob that the average
-Ursprüngliche Nachricht-
Von: Justin Erenkrantz
Until the protocol is fixed, we should do the right thing -
and that means we shouldn't ever allow the entire response to
be spooled in memory. -- justin
Actually we do not do this. The original code did this which lead to a
Hi,
I would love that we remove the FLUSHING_BANDAID from the code
because it concept breaks the AJP protocol specification.
Instead FLUSHING_BANDAID I propose that we introduce a new
directive 'flush=on' that would behave like the most recent
mod_jk directive 'JkOptions +FlushPackets'.
The
I am not concerned with the form of this feature's delivery -- as long
as it is well documented.
I will say that having an explicit flush that flushes up through the web
server is absolutely critical to certain use cases. Lack of this
functionality one way or another will break our apps.
-Ursprüngliche Nachricht-
Von: Mladen Turk
First: I am the author.
Hi,
I would love that we remove the FLUSHING_BANDAID from the code
because it concept breaks the AJP protocol specification.
I do not understand how this breaks the spec. There might be reasons
to handle
As someone who depends on such flushing I'd echo that we don't need
flushing after every AJP packet -- just when we explicitly call flush().
Plm wrote:
-Ursprngliche Nachricht-
Von: Mladen Turk
First: I am the author.
Hi,
I would love that we
Plüm wrote:
First: I am the author.
Cool. Did someone ever told you to that you
need to fix your mail client ;).
I hate your AW:AW:AW...
I would love that we remove the FLUSHING_BANDAID from the code
because it concept breaks the AJP protocol specification.
I do not understand how this
Mladen Turk wrote:
William A. Rowe, Jr. wrote:
support should be default (flushed) with the -option- to optimize for
those
apps who aren't harmed by streaming.
Right. We have two options, either to flush on each packet,
that BTW might or might not reflect the user 'out.flush();'
or keep
I would suggest that the bandaid code no longer be
compile time but rather runtime, using a
force-flush=true param to the AJP worker.
I agree that the current default may be right for
some, but majorly bad for others :) :)
On Mar 7, 2006, at 2:58 PM, Mladen Turk wrote:
William A. Rowe, Jr.
On 03/07/2006 07:19 PM, Mladen Turk wrote:
Plüm wrote:
First: I am the author.
Cool. Did someone ever told you to that you
need to fix your mail client ;).
I hate your AW:AW:AW...
Sorry I forgot to remove. Stupid Outlook at work. I don't use
it outside as you may notice.
I
Jim Jagielski wrote:
I would suggest that the bandaid code no longer be
compile time but rather runtime, using a
force-flush=true param to the AJP worker.
I agree that the current default may be right for
some, but majorly bad for others :) :)
Correct :)
I mean, now we have a flush no mater
On 03/07/2006 08:58 PM, Mladen Turk wrote:
William A. Rowe, Jr. wrote:
The current implementation breaks a simple timeout write:
out.write(Hello);
Thread.sleep(2000);
out.write(World);
It will send the 'Hello', but only after additional thread
finishes and times out.
Given the above
William A. Rowe, Jr. wrote:
For the benefit of folks here and not on mod_jk...
Check out jk_ajp_common.c in tomcat-5.5-connectors/jk/native/common
where whether the flush is forced for each JK_AJP13_SEND_BODY_CHUNK
is controlled by the FlushPackets. Also note how we vary
behavior at
On 03/07/2006 09:15 PM, Jim Jagielski wrote:
I would suggest that the bandaid code no longer be
compile time but rather runtime, using a
force-flush=true param to the AJP worker.
Just for clarification: What is your exact purpose?
1. Use the poll method of the bandaid, but make it possible
On 03/07/2006 10:10 PM, Jim Jagielski wrote:
William A. Rowe, Jr. wrote:
For the benefit of folks here and not on mod_jk...
Check out jk_ajp_common.c in tomcat-5.5-connectors/jk/native/common
where whether the flush is forced for each JK_AJP13_SEND_BODY_CHUNK
is controlled by the
On 3/7/06, Jim Jagielski [EMAIL PROTECTED] wrote:
I would suggest that the bandaid code no longer be
compile time but rather runtime, using a
force-flush=true param to the AJP worker.
I'd prefer that we not defer this decision to the users - we should
either enable it or don't. But, most
Justin Erenkrantz wrote:
Without FLUSHING_BANDAID, httpd will queue up the data when Tomcat
doesn't plan on writing any more. That's bad.
Unless/until AJP has a protocol revision, I think the code should stay
and be enabled by default. The only 'right' fix is to correct the
buggy underlying
Justin Erenkrantz wrote:
On 3/7/06, Jim Jagielski [EMAIL PROTECTED] wrote:
I would suggest that the bandaid code no longer be
compile time but rather runtime, using a
force-flush=true param to the AJP worker.
I'd prefer that we not defer this decision to the users - we should
either enable
Paul Querna wrote:
Justin Erenkrantz wrote:
Without FLUSHING_BANDAID, httpd will queue up the data when Tomcat
doesn't plan on writing any more. That's bad.
Unless/until AJP has a protocol revision, I think the code should stay
and be enabled by default. The only 'right' fix is to correct
On 03/07/2006 11:43 PM, Justin Erenkrantz wrote:
On 3/7/06, Jim Jagielski [EMAIL PROTECTED] wrote:
I would suggest that the bandaid code no longer be
compile time but rather runtime, using a
force-flush=true param to the AJP worker.
I'd prefer that we not defer this decision to the users
Ruediger Pluem wrote:
OTH I guess we still have to convince some people to switch from mod_jk
to mod_proxy_ajp. So I guess having a similar behaviour in mod_proxy_ajp
as in mod_jk will ease this. Default for mod_jk is: No flushing.
Then I'm confused, I thought this was reverted in the current
On 03/08/2006 12:49 AM, William A. Rowe, Jr. wrote:
Ruediger Pluem wrote:
OTH I guess we still have to convince some people to switch from mod_jk
to mod_proxy_ajp. So I guess having a similar behaviour in mod_proxy_ajp
as in mod_jk will ease this. Default for mod_jk is: No flushing.
On 03/08/2006 12:40 AM, Ruediger Pluem wrote:
The question that remains open to me is what kind of implementation should be
used
if force-flush is set to true?
The poll approach in the current code or flushing after each packet?
If the poll approach is used we need to make
I believe mod_jk added an explicit flush option rather than reverting
the default to flushing -- as I believe we suddenly had to add this
after our application stopped behaving properly and traced this issue back.
--
Jess Holle
William A. Rowe, Jr. wrote:
Ruediger Pluem wrote:
OTH I guess
For those in control of both endpoints, it would be nice to have a patch
to enable an extension to AJP in Tomcat 5.5.x and Apache 2.2 -- rather
than having to wait until Tomcat 6...
Of course, ideally said Tomcat patch would allow one to toggle at
runtime whether the extended protocol was
Justin Erenkrantz wrote:
On 3/7/06, Jim Jagielski [EMAIL PROTECTED] wrote:
I would suggest that the bandaid code no longer be
compile time but rather runtime, using a
force-flush=3Dtrue param to the AJP worker.
I'd prefer that we not defer this decision to the users - we should
either
27 matches
Mail list logo
