• View
• Edit
• History
• Print

VertxDirectories

.vertx directories being created

Edward wrote:

Running any of the REST or Websocket accessor demos or tests seems to result in vertx leaving turds in the file system. It leaves directories called .vertx that have empty directories named file-cache...

Apparently this is because we aren't calling close() on the instance of vertx defined in VertxHelperBase.java:

Summary

In theory, Vert.x-3.2.0-SNAPSHOT should delete the subdirectories in the .vertx/ directory via shutdown hooks. However, this did not work for me under Mac OS X. To get this to work, I had to modify the vert.x FileResolver deleteCacheDir() method so that it calls deleteRecursiveBlocking() instead of deleteRecursive().

I'll submit a bug report for this issue.

We could create a shutdown that would just remove the entire .vertx/ directory. The shutdown hooks may be run in any order, so if our shutdown hook was run first, then the Vert.x shutdown hooks would detect that the .vertx directory was missing.

One issue is that the .vertx directory is created in the current working directory, which could change by the time the shutdown hooks are invoked. Unfortunately, there is no way to get the cache directory from the FileResolver class. In addition, each FileResolver instance could have a separate .vertx/ directory if the current working directory changes, or the value of the vertx.cwd property changes.

Thus, to delete the .vertx/ directory, we would need to modify the vert.x FileResolver class.

A better solution would be to set the vertx.cacheDirBase to ~/.vertx. Note that we can't use /tmp/.vertx because multiple users would not be able to write to that directory.

Reproducing The Bug

This was submitted as https://github.com/vert-x3/issues/issues/72 and fixed in https://github.com/eclipse/vert.x/commit/a9db9646106d24e5f04a72aa0f4a17b4ba13c2f6

Set up Vert.x and add vertx to your path

Set up the Vert.x examples, see https://github.com/vert-x3/vertx-examples/tree/master/core-examples

Verify that the example works:

In the window where the above commands were run:

In another window:

In the client window, we see:

In the above, the Client connected to the Server and ran until I hit Control-C. Note that the .vertx directory contains one file-cache directory.

The Server window looks like:

After I stopped the Client, I stopped the Server with Control-C. The .vertx/ directory is empty.

The above indicates that the shutdown hooks ran successfully and removed the subdirectories in .vertx/.

To replicate the bug, we first compile the files:

In the above single quotes are needed to protect the * from expansion. The end results is all the jars in that directory are included in the classpath.

Next, we remove the .vertx directory if any:

Then, we start the server:

In our other window, we start the client:

In the client window, we stop the Client, put it in the background and we can see two subdirectories:

In the client window, we kill the background process and neither subdirectory is removed:

In the server window, we stop the process and neither subdirectory is removed:

Conclusion: When we run the echo Server/Client example with the vertx command, the subdirectories are removed.

However, when we run the echo Server/Client example Java classes as plain Java code the subdirectories are not removed.

Setting Properties

https://groups.google.com/forum/?fromgroups#!topic/vertx/7cBbKrjYfeI says:

Vert.x Uses Shutdown Hooks already to remove the subdirectories

In looking at the Vert.x code in 3.2.0-SNAPSHOT,

FileResolver has this code:

So, in the default, creating a FileResolver calls setupCacheDir(), which sets up a shutdownhook.

However, when we run PTII/ptolemy/actor/lib/jjs/modules/eventbus/demo/VertxChat/VertxChat.xml, with the latest vertx-core from github, then the directories are not reliably deleted.

.vertx Directory is not deleted by FileResolver.

Vert.x FileResolver.java does not delete the .vertx directory.

So, the above will delete the .vertx/file-cache-* directories, but not the .vertx directories themselves.

Two solutions

1. Create our own shutdown hook that calls close() and then deletes the .vertx directory. Note that there is no guarantee about the order the shutdown hooks will be called, so there is no way to know whether the shutdown hooks created in FileResolver will be called before or after our shutdown hook. Thus, if our shutdown hook calls close(), we need to read the code to see if the deletion of the subdirectories will occur before close() returns.
2. Set the property to not use this directory or set the property to be in the user's top level directory.

Using deleteRecursiveBlocking() causes the subdirectories to be removed.

If I modify Vert.x FileResolver.java so that deleteCache() calls deleteRecursiveBlocking() instead of deleteRecursive(), then the subdirectories are removed by the Vertx shutdown hooks.

Perhaps the VertxHelperBase should just remove the .vertx directory?

.vertx directories are not removed by close() in a non-clustered environment.

11/3/2015

I tried using a clustered environment, but that did not do it. My work is below. I updated VertxHelperBase so that a shutdown handler is created:

When I run $PTII/ptolemy/actor/lib/jjs/modules/eventbus/demo/VertxChat/VertxChat.xml, I can see that the shutdown hook is executed:

However, the .vertx directory is not removed.

Below is an analysis of the code.

VertxImpl.close() at https://github.com/eclipse/vert.x/blob/master/src/main/java/io/vertx/core/impl/VertxImpl.java looks like:

Thus, if eventBus is null, then deleteCacheDirAndShutdown() is not invoked.

eventBus is set by VertxImpl.createAndStartEventBus():

VertxImpl.createAndStartEventBus() is invoked VertxImpl(VertxOptions options, Handler<AsyncResult<Vertx>> resultHandler) for both clustered and unclustered options:

So, eventBus is non-null in both cases.

• Back to Vert.x