Request constructor cannot call set_close_after_request because it has not been registered with Server yet
Bug #497191 reported by
Darren Warner
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libvfcgi |
New
|
Undecided
|
Unassigned |
Bug Description
The following code in Connection.
new Request(this, m_server.
...constructs a new Request before it is added to the server. However, the Request constructor calls Connection.
if((m_flags & RequestFlags.
) {
...which checks Server to see if the request exists...
if(
m_closing_
... which it doesn't and an exception is thrown.
To post a comment you must log in.
This problem gets a little complex. Moving the set_close_ after_request( ) call into Connection (so that it can be registered after it exists in Server) still has the problem of when the request is created and destroyed within the call to Server. add_request( ), which is the current case with Server. default_ on_new_ request( ). The other solution is to remove the check in set_close_ after_request( ) - this makes things work but there exists the potential for race conditions. Really, the only solution would be to make adding the new request and registering it in Connection an atomic operation - ugly as things currently stand.
However, I think the real solution is that list of current request id's need to be managed in Connection, not Server. This is especially true when you consider that different web servers may all be communicating with a single libvfcgi-based application server, so that there exists the very likely possibility that we need to handle duplicate request id's simultaneously (the FGCI spec also aludes to this - "...the application keeps track of the current state of each request ID on a _given_ transport connection...").