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. > >
