On Tue, 2002-10-15 at 23:07, Bojan Smojver wrote: > > 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:
Yes, you're right, anything that tries to allocate conn_rec objects will have problems. > 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. Yes, that scenario is possible. And even without multiple virtual hosts, attributing bytes to the wrong request will make the logging a lot less useful to anyone who's trying to use the bytes_sent data for debugging or planning purposes. If we can come up with a way to delay the logging until after the response is actually sent, though, then the problem will disappear and your patch will produce much more accurate numbers. Brian
