Ales, do you have trace logs for the test so we can figure out how long an individual entry's preload is taking?

Running just this test takes almost none.

It's the full testsuite that gets stuck at one point, randomly atm.

Hence I suggest to setup the env, rather then decrypting this from trace log.

This is the only thread that seems to do any meaningful work in your thread dump:

Yeah, others are "serving" other AS7 subsystems.

Looks like lucene wants to read segments in memory before deleting them, and this takes a long time. Are you sure there's no data in the cache?

There could be some data -- probably is, otherwise it wouldn't take so long, right.

The funny thing is -- we try to delete it all on test::destroy,

otherwise it would break on de-marshalling -- as marshalling keeps the info about ModuleLoader,

which depends on the deployment name, where we use random Arquillian generated names.

Only in the tests/cases where we explicitly test persistence, do we use hardcoded names;

so that ModuleLoader' name is the same after re-start / de-marshalling.

Other thread dumps in-between show other Lucene usages,

hence not really sure what takes so long there.

But imagine a production env, where there is tons of data in the grid, and you do a server restart.

With this start-up time, it would take a few light years to start. :-)