Emtpy Vertx File Cache folders

[Terry Bleger]

Hi,

I'm getting a lot of empty .vertx/file-cache-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx folder everytime I ran my project. What and why is that?

[Thomas SEGISMONT]

I've noticed the same thing. The directories are created in io.vertx.core.impl.FileResolver. The Javadoc says they should be deleted on exit but they aren't.

Any reason not to use the temp directory as parent by default?

2015-06-29 18:31 GMT+02:00 Terry Bleger <terry...@gmail.com>:

Hi,

I'm getting a lot of empty .vertx/file-cache-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx folder everytime I ran my project. What and why is that?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Fox]

On 29/06/15 19:15, Thomas SEGISMONT wrote:

I've noticed the same thing. The directories are created in io.vertx.core.impl.FileResolver. The Javadoc says they should be deleted on exit but they aren't.

Do you have a reproducer that demonstrates them not being deleted?

I know there was a bug in earlier 3.0.0 snapshots but that should be resolved in the actual 3.0 release

Any reason not to use the temp directory as parent by default?

We used the system temp dir in Vert.x 2 and it was problematic. E.g. some Linux distros (e.g. RHEL?) by default have cron jobs which deleted tmp dir every day, which ended up with peoples servers just mysteriously stopping.

[Thomas SEGISMONT]

2015-06-29 20:30 GMT+02:00 Tim Fox <timv...@gmail.com>:

On 29/06/15 19:15, Thomas SEGISMONT wrote:

I've noticed the same thing. The directories are created in io.vertx.core.impl.FileResolver. The Javadoc says they should be deleted on exit but they aren't.

Do you have a reproducer that demonstrates them not being deleted?

I know there was a bug in earlier 3.0.0 snapshots but that should be resolved in the actual 3.0 release

It happens whenever I run ptrans integration tests. I'll try to build a test case.

 

Any reason not to use the temp directory as parent by default?

We used the system temp dir in Vert.x 2 and it was problematic. E.g. some Linux distros (e.g. RHEL?) by default have cron jobs which deleted tmp dir every day, which ended up with peoples servers just mysteriously stopping.

OK.

[Thomas SEGISMONT]

My bad, in test code a Vert.x instance was created but not closed properly. This explains why the cacheDir was not deleted.

How about skipping cacheDir creation when classpath resolving is disabled? It looks like it's not used in this case. Also, it would be nice to make the cacheDir parent directory configuration (CWD in 3.0.0).

[Terry Bleger]

Yeah Thomas was right. When using IDE (debugging, etc), cacheDir was never deleted because the vertx instance was never closed properly.

[Tim Fox]

On 30/06/15 09:20, Thomas SEGISMONT wrote:

My bad, in test code a Vert.x instance was created but not closed properly. This explains why the cacheDir was not deleted.

How about skipping cacheDir creation when classpath resolving is disabled? It looks like it's not used in this case.

Sounds reasonable, I will investigate.

We should also consider using runtime hooks to delete the cache dirs - this should avoid the case where the JVM was stopped without first stopping vert.x (unless the JVM is hard killed) and the dir wasn't deleted.

Could you add a BZ for this so we don't forget?

Also, it would be nice to make the cacheDir parent directory configuration (CWD in 3.0.0).

2015-06-29 22:20 GMT+02:00 Thomas SEGISMONT <tsegi...@gmail.com>:

2015-06-29 20:30 GMT+02:00 Tim Fox <timv...@gmail.com>:

On 29/06/15 19:15, Thomas SEGISMONT wrote:

I've noticed the same thing. The directories are created in io.vertx.core.impl.FileResolver. The Javadoc says they should be deleted on exit but they aren't.

Do you have a reproducer that demonstrates them not being deleted?

I know there was a bug in earlier 3.0.0 snapshots but that should be resolved in the actual 3.0 release

It happens whenever I run ptrans integration tests. I'll try to build a test case.

 

Any reason not to use the temp directory as parent by default?

We used the system temp dir in Vert.x 2 and it was problematic. E.g. some Linux distros (e.g. RHEL?) by default have cron jobs which deleted tmp dir every day, which ended up with peoples servers just mysteriously stopping.

OK.

[Thomas SEGISMONT]

2015-07-02 12:07 GMT+02:00 Tim Fox <timv...@gmail.com>:

On 30/06/15 09:20, Thomas SEGISMONT wrote:

My bad, in test code a Vert.x instance was created but not closed properly. This explains why the cacheDir was not deleted.

How about skipping cacheDir creation when classpath resolving is disabled? It looks like it's not used in this case.

Sounds reasonable, I will investigate.

We should also consider using runtime hooks to delete the cache dirs - this should avoid the case where the JVM was stopped without first stopping vert.x (unless the JVM is hard killed) and the dir wasn't deleted.

Could you add a BZ for this so we don't forget?

https://bugs.eclipse.org/bugs/show_bug.cgi?id=471674
 

[Tim Fox]

Thomas,

I've added a PR for these changes:

https://github.com/eclipse/vert.x/pull/1095

Could you review?