Leak due to VirtualFileURLConnection.class.urlCache() ----------------------------------------------------- Key: JBVFS-1 URL: http://jira.jboss.com/jira/browse/JBVFS-1 Project: JBoss VFS Issue Type: Bug Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: 2.0.0.Beta9 > I think I got another one. > There is a static ref to the VFS in VirtualFileURLConnection. In the end > the VirtualFile is kept in memory. See left bottom on the picture. If > these are the things to look for, then I got a bundle more. > Note that the VirtualFile is actually a reference to an EJB3 deployment, > so it's probably EJB3 code not cleaning up properly. But this shouldn't > lock down a ref in VFS. There is definately a memory leak in VirtualFileURLConnection.class.urlCache(). It grows without bounds. After an incomplete JBossWS test run 53 megs of heap is tied to this cache.

Leak due to VirtualFileURLConnection.class.urlCache() ----------------------------------------------------- Key: JBVFS-1 URL: http://jira.jboss.com/jira/browse/JBVFS-1 Project: JBoss VFS Issue Type: Bug Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: 2.0.0.Beta11 > I think I got another one. > There is a static ref to the VFS in VirtualFileURLConnection. In the end > the VirtualFile is kept in memory. See left bottom on the picture. If > these are the things to look for, then I got a bundle more. > Note that the VirtualFile is actually a reference to an EJB3 deployment, > so it's probably EJB3 code not cleaning up properly. But this shouldn't > lock down a ref in VFS. There is definately a memory leak in VirtualFileURLConnection.class.urlCache(). It grows without bounds. After an incomplete JBossWS test run 53 megs of heap is tied to this cache.

Leak due to VirtualFileURLConnection.class.urlCache() ----------------------------------------------------- Key: JBVFS-1 URL: http://jira.jboss.com/jira/browse/JBVFS-1 Project: JBoss VFS Issue Type: Bug Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: 2.0.0.CR1 > I think I got another one. > There is a static ref to the VFS in VirtualFileURLConnection. In the end > the VirtualFile is kept in memory. See left bottom on the picture. If > these are the things to look for, then I got a bundle more. > Note that the VirtualFile is actually a reference to an EJB3 deployment, > so it's probably EJB3 code not cleaning up properly. But this shouldn't > lock down a ref in VFS. There is definately a memory leak in VirtualFileURLConnection.class.urlCache(). It grows without bounds. After an incomplete JBossWS test run 53 megs of heap is tied to this cache.

Leak due to VirtualFileURLConnection.class.urlCache() ----------------------------------------------------- Key: JBVFS-1 URL: http://jira.jboss.com/jira/browse/JBVFS-1 Project: JBoss VFS Issue Type: Bug Reporter: Scott M Stark Assigned To: Marko Strukelj Fix For: 2.0.0.CR1 > I think I got another one. > There is a static ref to the VFS in VirtualFileURLConnection. In the end > the VirtualFile is kept in memory. See left bottom on the picture. If > these are the things to look for, then I got a bundle more. > Note that the VirtualFile is actually a reference to an EJB3 deployment, > so it's probably EJB3 code not cleaning up properly. But this shouldn't > lock down a ref in VFS. There is definately a memory leak in VirtualFileURLConnection.class.urlCache(). It grows without bounds. After an incomplete JBossWS test run 53 megs of heap is tied to this cache.

Leak due to VirtualFileURLConnection.class.urlCache() ----------------------------------------------------- Key: JBVFS-1 URL: https://jira.jboss.org/jira/browse/JBVFS-1 Project: JBoss VFS Issue Type: Bug Reporter: Scott M Stark Assignee: Marko Strukelj Fix For: 2.0.0.CR1 > I think I got another one. > There is a static ref to the VFS in VirtualFileURLConnection. In the end > the VirtualFile is kept in memory. See left bottom on the picture. If > these are the things to look for, then I got a bundle more. > Note that the VirtualFile is actually a reference to an EJB3 deployment, > so it's probably EJB3 code not cleaning up properly. But this shouldn't > lock down a ref in VFS. There is definately a memory leak in VirtualFileURLConnection.class.urlCache(). It grows without bounds. After an incomplete JBossWS test run 53 megs of heap is tied to this cache.