This has me thinking... we should likely do something to
better error-check the store/restore aspects of slotmem.
Even some sort of quick checksum would be better than
what we have now. :/

Gotta mull this over a bit more.

On Nov 8, 2013, at 1:29 PM, Jim Jagielski <[email protected]> wrote:

> Mostly due to the "persist" feature... Right now it just does
> a memcpy (basically). If people don't use it then it's not
> an issue.
> 
> 
> On Nov 8, 2013, at 10:00 AM, Thomas Eckert <[email protected]> 
> wrote:
> 
>>> I'd be +1 in adjusting all of those fields bigger, but I'm guessing
>>> that constitutes an API change for proxy...
>> 
>> API change, why is that ? At least the shm size stuff doesn't look like 
>> having a lot of implications other then memory consumption - to make sure of 
>> this assumption is why I asked in the first place. I can well imagine 
>> setting those defaults at build time, possibly with a directive for 
>> performance fine tuning at post-build time.
>> 
>> 
>> 
>> On Fri, Nov 8, 2013 at 3:35 PM, Jim Jagielski <[email protected]> wrote:
>> Yeah, it's basically for performance and storage reasons (since those
>> strings are stored in shm)... Nowadays I don't think shm is such an
>> expensive commodity, though I can imagine some setups where the
>> default sizes allowed by the kernel could be kinda small.
>> 
>> I'd be +1 in adjusting all of those fields bigger, but I'm guessing
>> that constitutes an API change for proxy...
>> 
>> On Nov 8, 2013, at 5:17 AM, Thomas Eckert <[email protected]> 
>> wrote:
>> 
>>> I'm looking at an issue with this log message
>>> 
>>>  AH00526: Syntax error on line 6 of myconfig.conf: BalancerMember worker 
>>> hostname (aaaaaaaa-bbbb-cccc-dd-eee-ffffffffff.us-east-1.elb.amazonaws.com) 
>>> too long
>>> 
>>> with the root cause being (modules/proxy/mod_proxy.h)
>>> 
>>>  #define PROXY_WORKER_MAX_HOSTNAME_SIZE  64
>>> 
>>> and I'm wondering why this is. I did not see any comments on why there is 
>>> this limit, so I assume it's for performance reasons.
>>> 
>>> Also, I'm wondering what the implications (if any) of altering this limit 
>>> are.
>> 
>> 
> 

Reply via email to