Quoting Brian Pane <[EMAIL PROTECTED]>: > On Tue, 2002-10-15 at 22:09, Bojan Smojver wrote: > > I have submitted the patch along those lines a few days back, which also > > includes an MMN bump. In the light of the latest discussions on the list, > it > > seems that a patch like that is not being looked at favourably by many > people :-( > > The MMN bump in this case is no problem. Your patch just adds > fields at the end of the structure. It's backward compatible, > so it only needs an increase in the MMN minor number, not the > major number. If the patch added fields in the middle of the > struct, thus breaking binary compatibility, then it would be > a problem.
What if someone creates an array of conn_rec structures in their module? Isn't the code that fetches the next one going to be incorrect? For instance: conn_rec c[5]; c[1].not_the_first_field = some_value; /* OOPS, we'll probably get garbage */ > > Do you want me to rework that patch so it uses a privata data structure > (to > > avoid MMN bump) rather then two new fields in conn_rec? Or is the quality > of the > > patch unacceptable in general? > > I've only had a couple of minutes to look at the patch (too busy > with my day job this week), but I think the basic problem with the > patch is that you're updating the bytes-sent field in the conn_rec > after the writes complete in the core_output_filter, but you're > reading that field in a logger function. But the logger function > can be called *before* the socket write happens. When handling > keep-alive requests, for example, the server may buffer up a > small response to one request but not send it until the next > response is generated. The first request gets logged as soon as > all the response data is sent to core_output filter, so the > mod_logio logging code might find that the bytes-sent value > in the conn_rec is zero because the socket write hasn't actually > happened yet. > > The best solution is to delay the logging until after the response > has actually been sent. This would require more significant > changes to the server, though. Most of the data that the logger > needs is in the request's pool. Currently, this pool is cleared > as soon as we send the response to the core_output_filter and log > it. In order to accurately log the bytes sent, we'd have to keep > the request pool around until the last of the that request's > response data was written. That's not impossible, but it would > require some design changes to the httpd core and the output > filters. IMHO, that's a good example of a worthwhile design > change to make for 2.1. OK. I think I finally understand what the problem is here. That's what William was trying to explain to me before, but because I don't know the guts of Apache 2 all that well, I didn't understand :-( Basically, what would be happenning with the patch is that the numbers would be logged with the next request, rather then this one. However, if the data was SENT with the next request, then it should be LOGGED with the next request. This seems like the question of semantics to me. The problem I can see with this is the following: - connection opened (keepalive) - request for aaa.domain - not sent (i.e. the server is buffering it) - logged zero output - request for bbb.domain (on the same connection) - sent - logged bytes out for bbb.domain PLUS aaa.domain Is something like this possible? If not, I think we should be pretty much OK as the whole point of mod_logio is to log the traffic, most likely per virtual host. Bojan
