In support of this latest theory is the fact that YourKit shows two GC
roots for the HttpRequest. Apart from the
com.caucho.server.port.TcpConnection._request reference, the request is
a root itself by being on the stack of a thread (http--8080-...).
This could indicate a thread currently waiting in the
com.caucho.server.port.TcpConnection.run() method, where the
ServerRequest of the parent is also a local variable.
Even if the request is reused, I believe the Invocation or the
ClassLoader of the invocation needs to be reset somehow, to release the
I can help try out a proposed fix to see if it solves the problem (=
feel free to mail me off list). I might even give it a shot myself.
Mattias Jiderhamn wrote (2008-11-04 23:28):
> Scott Ferguson wrote (2008-11-04 23:16):
>> On Nov 4, 2008, at 2:10 PM, Mattias Jiderhamn wrote:
>>> Scott wrote:
>>>> Did you build from resin/branches/3.1 or the trunk?
>>> 3.1 branch.
>>> Now I'm browsing around the
>>> com.caucho.server.port.TcpConnection._request which is never
>>> explicitly release, but I realize it's getting a bit too late on this
>>> side of the Atlantic ocean so I better continue tomorrow unless you
>>> find the source of the problem until then.
>> That field is never released. The TcpConnection, Request and Response
>> triple are reused together.
> Wouldn't that be the problem then?
> As long as there is one such triplet that has not been reused since the
> webapp was reloaded, the request will point to (the Invocatoin that will
> point to) the classloader of the old version of the app?
> (That could also explain why the problem has seemed to appear more often
> on low load test sites than on production instances.)
resin-interest mailing list