On 03/08/2006 03:46 AM, Jim Jagielski wrote:
> How about something like this? I whipped this out very quickly
> and just did some quick compile and config-test tests on it...
> Comments before I commit sometime tomorrow:
Basicly looks good to me. Thanks for doing so. Some comments inline.
>
> -
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
How about something like this? I whipped this out very quickly
and just did some quick compile and config-test tests on it...
Comments before I commit sometime tomorrow:
Index: modules/proxy/mod_proxy_ajp.c
===
--- modules/proxy/mod_
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 used
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
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 FLU
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.
Quoting Bojan Smojver <[EMAIL PROTECTED]>:
Nice. If I were to work on the patches along those lines, is there a
starting point maybe? An initial set of uncommitted patches? API
suggestions?
OK, I'll have stab then. Here is what I had in mind:
- all AP_INIT_TAKE1 become AP_INIT_TAKE2, all AP_
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 m
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 decis
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 th
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 ena
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 pr
[ http://issues.apache.org/jira/browse/MODPYTHON-107?page=all ]
Work on MODPYTHON-107 started by Graham Dumpleton
> mod_python.publisher shouldn't flush result when written.
> -
>
> Key: MODPYTHON-107
> URL: http:
[ http://issues.apache.org/jira/browse/MODPYTHON-107?page=all ]
Graham Dumpleton reassigned MODPYTHON-107:
--
Assign To: Graham Dumpleton
> mod_python.publisher shouldn't flush result when written.
> ---
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, m
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 b
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 pos
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 JK_AJP
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.
Giv
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 mat
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 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.
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 lik
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 like it is right now (flu
Plüm wrote:
As a summary from your side I see:
1. Extend AJP protocol [The desired target from my view].
Desireable to line up with, say, Tomcat6. But this really doesn't help the
installed base of Tomcat 4/5, right? With the evolving spec, progressive
java prereqs, it's pretty easy for some
On 3/7/06, Brian Candler <[EMAIL PROTECTED]> wrote:
> I'm not sure what you mean there, in particular what you mean by 'assumes
> that you can make multiple connections to back end fastcgi processes'
>
> What I'm familiar with is apache 1.x with mod_fcgi. In that case, the
> typical fastcgi progra
On Sun, Mar 05, 2006 at 03:06:09PM -0800, Garrett Rooney wrote:
> First of all, mod_proxy_balancer really assumes that you can make
> multiple connections to back end fastcgi processes at once. This may
> be true for some things that speak fastcgi (python programs that use
> flup to do it sure loo
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
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().
Plüm wrote:
-Ursprüngliche Nachricht-
Von: Mladen Turk
First: I am the author.
Hi,
I would love that we r
> -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 ha
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.
--
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 poi
> -Original Message-
> From: Daniel Rogers [mailto:[EMAIL PROTECTED]
> Sent: Montag, 6. März 2006 19:01
>
>
> The end user sees only port 443. No worries about weird port numbers.
Ok - I read the post and I agree your solution doesn't rely on using a
non-standard port externally. I wa
34 matches
Mail list logo
