Hi everyone, I was hoping someone might have an idea on this. So EventProcessor relies on two #defines when it's constructed namely MAX_EVENT_THREADS and MAX_THREADS_IN_EACH_TYPE (see I_EventProcessor.h), as of now they are both set to 512. Unfortunately, if you wanted to use ATS to listen on a large number of ports (500+) this becomes a problem if you're using accept threads.
So I wanted to remove these #defines and potentially make them configurable as part of my fix for the arbitrary limit on the number of ports you can listen on… The catch: eventProcessor is a global so it's constructed before main() and therefore the configuration stuff hasn't been initialized yet and I do not have access to anything in records.config. Does anyone have ideas? Here are a few things I considered: 1. change EventProcessor eventProcessor; to EventProcessor *eventProcessor; and construct it on the heap at a point in initalize_process_manager() in main.cc after RecProcessorInit so I can guarantee that the constructor of EventProcessor has access to the records.config data it would need. The problem with this approach would be that: can I guarantee that I would need eventProcessor before that main, I think it's safe to assume that delayed construction of eventProcessor should be ok because from what I can tell nothing up until that point uses eventProcessor. Secondly I would have to replace all instances of eventProcessor. to eventProcessor-> or (*eventProcessor). Would that be problematic in anyway? I did a quick search and it's something like 200+ substitutions (ouch). 2. Just set the limits pretty high, such as 4096 for MAX_EVENT_THREADS and 2048 for MAX_THREADS_IN_EACH_TYPE, this would mean that you could potentially use accept threads to listen on 4000+ ports with a single instance of ATS, and I sort of feel this pretty much resolves the bug. The only caveat is that there would be a slightly higher memory footprint (just a couple of kb) since the array being constructed with these #defines is an array of pointers, I feel that this is a negligible tradeoff and shouldn't be an issue at all. So I would love to know if anyone has ideas for what the best way to approach this might be, do I just bump up the limits or do I invest in a potentially big overhaul just to get those two things records.configurable? Thanks. Brian
