[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Alternative vfs jar implementation

mstruk do-not-reply at jboss.com
Tue May 27 12:25:50 EDT 2008


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#4153696

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153696



More information about the jboss-dev-forums mailing list