On 09.03.2011 14:46, Mark Thomas wrote:
On 09/03/2011 05:41, Rainer Jung wrote:
Hi all,
some things I noticed while implementing the new switch:
- o.a.c.connector.Request and Response hav methods finishRequest() resp.
finishResponse(). The mehod in the request seems not to be called.
Although that's not a big issue, because the omplementation is empty,
one would run into trouble when starting to add code to it (at least I
wondered why it wasn't working)
That looks like an oversight.
Any idea about a good place from where to call? finishResponse is called
from CoyoteAdapter and CometEventImpl. At least we could call
request.finishRequest() form inside response.finishResponse().
- Should we keep the swallow default in TC 7 (default is "do swallow",
i.e. read all of the remaining bytes, thereby keeping the thread busy
for a possibly long time but also keeping browsers happy which will
otherwise most likely not read the response). I'd say "keep swallowing"
but had the impression that Mark is more concerned about it and prefers
the "do not swallow" default.
I thought the default was do not swallow. The important thing is that
this patch doesn't change the default.
Terminology: AbstractInputBuffer has a flag called swallowInput, which
is true by default. True means: read additional data after the end of
the response (drain the connection). This default is not changed.
Our new config item is called swallowAbortedUploads, again default is
"true", i.e. drain the connection until no more data. Unchanged from
before the patch.
From a performance point of view, I think do not swallow and close the
connection is the right thing to do.
OK, so that's something the admin or dev has to enable explicitely via
the config.
- Domain and path of the session cookie are listed in config/context.xml
as configurable per context. The name is not listed, although the setter
is there and the value is respected in ApplicationSessionCookieConfig.
Is this an oversight? Should I add the name to the context parameter
list in the docs?
Yep, that is an oversight. If you could add it that would be great.
Will do.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
