We're employing the 'hot deploy' feature in jetty to redeploy an updated webapp.
What we're observing is that the redeployment doesn't discard the disk resources of the prior deployment. Using 'lsof' as such: lsof -nP +L1 /var | grep /var | grep '(deleted)' | less We can see dozens of old deployments (old extracted war files?), like this: java 26734 root 82r REG 8,6 575389 0 32470 /var/tmp/webapp_tmp/jetty-0.0.0.0-80-webapp-_idp-any-4794158382650079166.dir/webinf/WEB-INF/lib/commons-collections-3.2.1.jar (deleted) java 26734 root 110r REG 8,6 575389 0 32561 /var/tmp/webapp_tmp/jetty-0.0.0.0-80-webapp-_idp-any-2567933012053298590.dir/webinf/WEB-INF/lib/commons-collections-3.2.1.jar (deleted) java 26734 root 318r REG 8,6 575389 0 40227 /var/tmp/webapp_tmp/jetty-0.0.0.0-80-webapp-_idp-any-4949209254558295977.dir/webinf/WEB-INF/lib/commons-collections-3.2.1.jar (deleted) ... As the JVM is still holding a reference, the disk space never frees, and our /var/ partition eventually fills. :/ Do other people see this? Are we doing this wrong? All we did was modify the scanInterval setting to a nonzero value. Is there some configuration switch we can throw to coerce the JVM to really release these resources, or are we stuck waiting for the GC to eventually cleanup? Details of our environment: jetty-distribution-9.3.8.v20160314 OpenJDK Runtime Environment (build 1.8.0_71-b15) CentOS release 6.7 (Final) # uname -r 2.6.32-573.18.1.el6.x86_64 -- Brian Reichert <[email protected]> BSD admin/developer at large _______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
