TS-4302 Adds more control over the event API to use#548
TS-4302 Adds more control over the event API to use#548zwoop wants to merge 1 commit intoapache:masterfrom
Conversation
|
This looks reasonable to me. Eventually it might make sense to make this selection at run time? Now that we have it, please update |
|
Thanks, yeah, I'll update the configuration. Yeah, it might make sense to make this selection at runtime, but of course it must also check for the existence of available eventers. @jpeach Would you be a peach and file a Jira on making this run-time selectable? It seems low importance, because the primary platform we support (Linux) really only supports epoll(). |
|
Hmmm, I don't know that it makes sense to add that document, we don't document most of the options in configure.ac, and there is a "help" message for this new option (configure --help) |
|
OK. I was thinking that we would start (continue?) documenting build process/dependencies/options more. |
|
@jpeach Agreed. Can you file another Jira, and ask jsime to add a section to this document where we document all options to configure ? That makes more sense than adding this new one (which is almost never going to be used). |
…ache#548) This could possibly be considered a bug, but certainly it's not a great behavior as it was. Before this patch, filters (as defined and used with .definefilter and .activatefilter), are always all evaluated, with a priority towards deny. ip_allow.yaml however works by evaluating only filters up until one matches, and whatever action has triggered, is used. This patch changes these remap filters to follow the behavior of ip_allow.yaml. First filter that matches is applied, and evaluation of filters stops. I would really have liked to see this in 9.2.x, but I'm not so sure that it's a good idea since it does also break compatibility even if we consider this a bug. (cherry picked from commit 1cccda1) Co-authored-by: Leif Hedstrom <zwoop@apache.org>
) (apache#548)" This reverts commit 0d508ef.
2 participants
This also addresses the build problems on current Illumos, by prioritizing the ports interface. But as such, it can now be useful to allow overriding this, with an explicit configure option (since Illumos now supports both epoll and ports).