On Wed, Apr 27, 2016 at 9:30 PM, William A Rowe Jr
wrote:
> On Wed, Apr 27, 2016 at 6:16 PM, Yann Ylavic wrote:
>
>>
>> So now, either we choose to not report workers' activity in between
>> requests (there are just multi-purpose workers/request-pollers after
>> all), or we save some "last reque
On Wed, Apr 27, 2016 at 6:16 PM, Yann Ylavic wrote:
> I was offline today so couldn't comment on the different messages on
> the subject, so I'll try to summarize (here) my understanding, so
> far...
>
> On Wed, Apr 27, 2016 at 8:41 PM, wrote:
> > Author: wrowe
> > Date: Wed Apr 27 18:41:49 201
On Thu, Apr 28, 2016 at 2:40 AM, Yann Ylavic wrote:
>>
>> What I saw was memory nullified, by assumedly, new apr_pcallocs, that should
>> not have been freed already. With more likelihood the more load and the less
>> logging, of course.
>
> So I'm rather thinking of a pool lifetime issue in h2
On Wed, Apr 27, 2016 at 7:28 AM, Stefan Eissing
wrote:
>
>
>> Am 26.04.2016 um 23:57 schrieb Yann Ylavic :
>>
>> On Tue, Apr 26, 2016 at 4:49 PM, Stefan Eissing
>> wrote:
>>> Today I Learned the difference between writing
>>> DATA + META
>>> and
>>> DATA + META + FLUSH
>>> to the core output fi
I was offline today so couldn't comment on the different messages on
the subject, so I'll try to summarize (here) my understanding, so
far...
On Wed, Apr 27, 2016 at 8:41 PM, wrote:
> Author: wrowe
> Date: Wed Apr 27 18:41:49 2016
> New Revision: 1741310
>
> URL: http://svn.apache.org/viewvc?rev
Within h2_task.c, we have
static apr_status_t h2_task_process_request(h2_task *task, conn_rec *c)
{
const h2_request *req = task->request;
conn_state_t *cs = c->cs;
request_rec *r;
ap_log_cerror(APLOG_MARK, APLOG_TRACE1, 0, c,
"h2_task(%s): create request_rec", t
So just to summarize how in h2 there may be issues...
modules/http2/h2_conn_io.c:ap_update_child_status_from_conn(c->sbh,
SERVER_BUSY_WRITE, c);
- this will trash any request line info
modules/http2/h2_task.c:ap_update_child_status(c->sbh,
SERVER_BUSY_READ, r);
- is only appropria
Change was done in http://svn.apache.org/viewvc?view=revision&revision=327872
by brianp in 2005 with message:
"New version of ap_core_output_filter that does nonblocking writes
(backport from async-dev branch to 2.3 trunk)"
Since Brian put his name in CHANGES, it was probably him...
-Stefan
For example... in event.c;
if (cs->pub.state == CONN_STATE_WRITE_COMPLETION) {
int not_complete_yet;
ap_update_child_status_from_conn(sbh, SERVER_BUSY_WRITE, c);
Yuck, that just trashed the score for that connection.
We do it again here;
if (cs->pub.state == CONN_STATE_
I'm not certain the error is -in- scoreboard.c.
Suspecting that we used to call ap_update_child_status[_xxx] with the
NULL req/conn rec pointer when we were idling for keepalive or ending the
request.
It seems we may now be calling it in these situations with a now-NULL
req_rec
and the dying/idlin
+1...
I had just applied the patch in STATUS w/o seeing this thread.
Best to just revert this all and get back to 2.4.18 behavior
(and code)
> On Apr 27, 2016, at 12:40 AM, Stefan Eissing
> wrote:
>
>
>
>> Am 27.04.2016 um 03:53 schrieb William A Rowe Jr :
>>
>>
>> My gut instinct is to pr
On 27 Apr 2016, at 2:49 PM, Stefan Eissing wrote:
> I had a look into 2.4.x this morning and while there are changes in filter
> brigade setaside code, the basic "cleanup" of empty and meta buckets before
> the setaside is there already.
>
> I think this has not bween noticed before as
> 1. E
> Am 27.04.2016 um 14:10 schrieb Jim Jagielski :
>
> Grrr... w/o looking too deeply into this, this seems very
> wrong. Is that a long-standing bug or something recently
> "optimized" away?
I had a look into 2.4.x this morning and while there are changes in filter
brigade setaside code, the bas
On Wed, Apr 27, 2016 at 7:20 AM, wrote:
> Author: jim
> Date: Wed Apr 27 12:20:57 2016
> New Revision: 1741239
>
> URL: http://svn.apache.org/viewvc?rev=1741239&view=rev
>
> Modified:
> httpd/httpd/branches/2.4.x/STATUS
>
> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL:
> http://svn.apach
In the 2.4 STATUS file there are 2 backports which, I think,
would be exceptional if we could get in 2.4 asap. They are
the dynamic health check and the http/2 proxy stuff.
These are some killer features and would be great to have
httpd 2.4 be the web server/reverse proxy that brings 'em
to the pe
Grrr... w/o looking too deeply into this, this seems very
wrong. Is that a long-standing bug or something recently
"optimized" away?
> On Apr 26, 2016, at 10:49 AM, Stefan Eissing
> wrote:
>
> Today I Learned the difference between writing
> DATA + META
> and
> DATA + META + FLUSH
> to the
On 26 Apr 2016, at 4:49 PM, Stefan Eissing wrote:
> Today I Learned the difference between writing
> DATA + META
> and
> DATA + META + FLUSH
> to the core output filters. I am astonished that
> my code ever worked.
>
> Seriously, what is the reason for this kind of
> implementation? I would
On 27/04/2016 8:56 AM, Yann Ylavic wrote:
Thanks, done in r1741112 and r1741115.
Regards,
Yann.
Excellent! All httpd-trunk now builds nicely with NetWare.
On Wed, 27 Apr 2016, Stefan Eissing wrote:
The h2 use case is to pass a meta bucket that, when destroyed,
signals the end of life for data belonging to one stream. So all
buckets before that one should have been either destroyed or
setaside already.
One workaround could be a custom (data)
19 matches
Mail list logo
