
<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite">Ales, do you have trace logs for the test so we can figure out how long an individual entry's preload is taking?<br></blockquote><div><br></div><div>Running just this test takes almost none.</div><div>It's the full testsuite that gets stuck at one point, randomly atm.</div><div>Hence I suggest to setup the env, rather then decrypting this from trace log.</div><br><blockquote type="cite">This is the only thread that seems to do any meaningful work in your thread dump:<br></blockquote><div><br></div><div>Yeah, others are "serving" other AS7 subsystems.</div><div><br></div><blockquote type="cite"><font size="-1">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?<br>

<br></font></blockquote></div><br><div>There could be some data -- probably is, otherwise it wouldn't take so long, right.</div><div><br></div><div>The funny thing is -- we try to delete it all on test::destroy,</div><div>otherwise it would break on de-marshalling -- as marshalling keeps the info about ModuleLoader,</div><div>which depends on the deployment name, where we use random Arquillian generated names.</div><div><br></div><div>Only in the tests/cases where we explicitly test persistence, do we use hardcoded names;</div><div>so that ModuleLoader' name is the same after re-start / de-marshalling.</div><div><br></div><div>Other thread dumps in-between show other Lucene usages,</div><div>hence not really sure what takes so long there.</div><div><br></div><div>But imagine a production env, where there is tons of data in the grid, and you do a server restart.</div><div>With this start-up time, it would take a few light years to start. :-)</div><div><br></div><div>-Ales</div><div><br></div></body></html>