You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2014/08/29 20:27:23 UTC
PROXY_WORKER_MAX_NAME_SIZE
I'd like to propose that we bump up PROXY_WORKER_MAX_NAME_SIZE
again, both in trunk but also allow for backporting to
2.4.x as well.
Re: PROXY_WORKER_MAX_NAME_SIZE
Posted by Jim Jagielski <ji...@jaguNET.com>.
Addressed in r1621367 and r1621382
Bytes are cheap... should we bump up any others?
On Aug 29, 2014, at 4:25 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> The problem is that we need a name for the matching... And
> we use shm for performance reasons...
>
> On Aug 29, 2014, at 3:33 PM, Dirk-Willem van Gulik <di...@webweaving.org> wrote:
>
>>
>>> On 29 Aug 2014, at 21:05, Jim Jagielski <ji...@jaguNET.com> wrote:
>>>
>>> FWIW, this is reported in
>>>
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=53218
>>>
>>> I was thinking of a dual-approach: Increase PROXY_WORKER_MAX_NAME_SIZE
>>> and making the truncation of the worker name (s->name) non-fatal
>>> (but logged at ALERT)...
>>>
>>
>> I've been bitten by this quite a few times as well. And always when you least expect it.
>>
>> Wondering if it is time to push long names into a uuid or hash; with a translation table/db file if needed.
>>
>> Dw.
>>
>>>> On Aug 29, 2014, at 2:27 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>>>
>>>> I'd like to propose that we bump up PROXY_WORKER_MAX_NAME_SIZE
>>>> again, both in trunk but also allow for backporting to
>>>> 2.4.x as well.
>>>
>
Re: PROXY_WORKER_MAX_NAME_SIZE
Posted by Jim Jagielski <ji...@jaguNET.com>.
The problem is that we need a name for the matching... And
we use shm for performance reasons...
On Aug 29, 2014, at 3:33 PM, Dirk-Willem van Gulik <di...@webweaving.org> wrote:
>
>> On 29 Aug 2014, at 21:05, Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>> FWIW, this is reported in
>>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=53218
>>
>> I was thinking of a dual-approach: Increase PROXY_WORKER_MAX_NAME_SIZE
>> and making the truncation of the worker name (s->name) non-fatal
>> (but logged at ALERT)...
>>
>
> I've been bitten by this quite a few times as well. And always when you least expect it.
>
> Wondering if it is time to push long names into a uuid or hash; with a translation table/db file if needed.
>
> Dw.
>
>>> On Aug 29, 2014, at 2:27 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>>
>>> I'd like to propose that we bump up PROXY_WORKER_MAX_NAME_SIZE
>>> again, both in trunk but also allow for backporting to
>>> 2.4.x as well.
>>
Re: PROXY_WORKER_MAX_NAME_SIZE
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> On 29 Aug 2014, at 21:05, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> FWIW, this is reported in
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=53218
>
> I was thinking of a dual-approach: Increase PROXY_WORKER_MAX_NAME_SIZE
> and making the truncation of the worker name (s->name) non-fatal
> (but logged at ALERT)...
>
I've been bitten by this quite a few times as well. And always when you least expect it.
Wondering if it is time to push long names into a uuid or hash; with a translation table/db file if needed.
Dw.
>> On Aug 29, 2014, at 2:27 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>> I'd like to propose that we bump up PROXY_WORKER_MAX_NAME_SIZE
>> again, both in trunk but also allow for backporting to
>> 2.4.x as well.
>
Re: PROXY_WORKER_MAX_NAME_SIZE
Posted by Jim Jagielski <ji...@jaguNET.com>.
FWIW, this is reported in
https://issues.apache.org/bugzilla/show_bug.cgi?id=53218
I was thinking of a dual-approach: Increase PROXY_WORKER_MAX_NAME_SIZE
and making the truncation of the worker name (s->name) non-fatal
(but logged at ALERT)...
On Aug 29, 2014, at 2:27 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> I'd like to propose that we bump up PROXY_WORKER_MAX_NAME_SIZE
> again, both in trunk but also allow for backporting to
> 2.4.x as well.
>