> 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. :-) -Ales
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
