anonymous wrote : I don't see why this asynch behavior is necessary. Maybe I should explain a little :) There is a tradeoff between performance and releasing of file locks when it comes to zip files. Every opening of a zip file comes with an overhead. So - to maximize performance, you open a zip file (acquire a lock) and never release it. That's how current trunk works, and we don't like it for obvious reasons. So I implemented the other extreme. For every file that was read from a zip archive a zip file was opened, file was read, and then a zip file was closed right away. This resolved the locking problem but came with a performance penalty - reopening a zip file for every entry. To have the best of both worlds the obvious solution is to not close a zip file immediately after every use, so that the next time an already open file can be reused, but still close it after a few seconds so that locks are being released. Now, you have no guarantee after any call to VFS that another call will occur within a reasonable time. If the last call left the zip file open the file may remain open for a long time. There are only two alternatives that I see here - use a third thread, or mandate at the level of VFS API that clients need to do polling - either through existing method - like getLastModified() - or through special method. The third-thread-option seems less nasty to me than relying on API client for proper operation. Although I suppose MC's VFS deployer does a regular polling and maybe could be relied upon in this matter? Also consider that release period will then be defined by MC's polling period in that it can only be a period of that, and can't be shorter than that. My implementation on the other hand is completely autonomous. It uses a daemon timer thread, that autodetects lack of activity and cancels itself out - getting reinitialized when activity reoccurs. So a third thread only exists for a brief period of time - at start up and at redeployment, other times it's not even there. - marko View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153696#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...