#modules
Posts
-
Digging into Kafka's Source 2: The Big Picture — Clients, Brokers, Controllers and Partitions
A big-picture map for intermediate developers opening the Kafka source for the first time. Starting from the main method of kafka.Kafka that kafka-server-start.sh calls, we follow how process.roles decides whether BrokerServer, ControllerServer and SharedServer get built, what a broker creates when it starts, how the controller decides topics, partitions and leaders through the metadata log and spreads them to the brokers, how a client finds a leader through a Metadata response, and which way the modules depend on each other — all checked against the real source and examples I actually ran — and we mark which part of the map Parts 3–12 zoom into.
-
Digging into nginx's Source 2: The Big Picture — Master and Workers, Modules, the Cycle and Config Contexts
The map for the whole series, written for intermediate programmers opening the nginx source for the first time. Where the single master and the workers each spend their time waiting, how every feature plugs in as one ngx_module_t and why module types are the ASCII letters "CORE" and "HTTP", what ngx_cycle_t and conf_ctx hold for a running nginx, how the main, events, http, server and location contexts of nginx.conf are checked with bit flags, and how one worker's event loop juggles hundreds of connections — all checked against the real source with ps and gdb examples.
-
Digging into nginx's Source 5: Modules and Directives — How One Line of nginx.conf Becomes a Module's Config Struct
An nginx module is a single ngx_module_t struct, and a directive is one row in the ngx_command_t table that struct points to. We follow the module array configure generates, dynamic modules read with load_module, ngx_conf_handler() finding a function by directive name, ngx_http_block() creating per-module config structs for every http, server and location, and the merge that finishes once, at config time. We build a dynamic module with four directives to watch the callback order, the merged values and the error messages.
-
Digging into Apache httpd's Source 2: Before Reading a Server Written in C — Structs, Function Pointers, Macros
Where does the saying "C structs are more beautiful than C++ or Java objects" come from? Without classes or interfaces, how does httpd plug modules in? We check it against the real source and real runs — memory layout with nothing hidden, interfaces built from function pointers, a void * array indexed by module_index, hook functions stamped out by macros, the MMN check that lets httpd trust a separately compiled .so — and the things C will not do for you.
-
Digging into Apache httpd's Source 3: The Big Picture — Core, APR, MPM, Modules and the Three Big Structs
A map for anyone opening the Apache httpd source for the first time. We look at the layers (operating system, APR, core, MPM, modules), why even the core is a module, how modules compiled into the binary differ from ones loaded with LoadModule, the three structs server_rec, conn_rec and request_rec, the pool hierarchy, and the path a single request takes — all checked against the real source and examples I actually ran.
-
Digging into Apache httpd's Source 6: Modules and Hooks — How a Module Plugs into the Server
Nearly every feature of httpd is a module, and a module plugs into the server by attaching functions to fixed points called hooks. Using the source at a pinned commit and three small modules written for this post, we look at the module struct, the two ways a module gets registered (static modules and LoadModule), what the hook macros really expand to, how RUN_FIRST differs from RUN_ALL, and how the call order is decided from order values and the names of other modules.
-
Digging into Apache httpd's Source 7: The Config File and Directives — How One Line of httpd.conf Becomes a C Struct
How does one line you write in httpd.conf end up calling a module's C function and filling in a struct? We follow server/config.c — reading the file into a tree and then walking it, the hash that finds a directive by name, argument styles like TAKE1, FLAG and ITERATE, the bit test behind "not allowed here" and AllowOverride, and when the values in Directory, Location and VirtualHost sections get merged — all checked with a directive we wrote ourselves.
-
Digging into Spring's Source 2: The Big Map — Modules and Packages
A map for anyone opening the Spring Framework repository for the first time. What each of the 22 modules does, how they depend on one another, what lives inside spring-core, spring-beans, spring-context and spring-aop, and the big picture of container start-up — all checked against the real build files and source.