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 webapp classloader. 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 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.) > > /Mattias >
_______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
