[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-228?pag... ] Emmanuel Bernard updated HSEARCH-228: ------------------------------------- Fix Version/s: (was: 3.1.0) 3.1.0.CR1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-228?pag... ] Hardy Ferentschik reassigned HSEARCH-228: ----------------------------------------- Assignee: Hardy Ferentschik -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-228?pag... ] Sanne Grinovero commented on HSEARCH-228: ----------------------------------------- I am also wondering how to do it; To detect concurrency problems you either need to write highly complex testcases to actively control different interleaving scenarios, or rely on random thread interleaving scenarios by applying a very high load and an "unreasonable high" number of threads (to add more randomness), of course running for long times. In an infinite resources project apply both strategies :-) So even if the most common use case of H.Search would be "behind tomcat" this would prevent you to achieve the high concurrency needed to eventually detect bugs in a reasonable test time: two days of testing results in no problem being detected, this doesn't mean you wouldn't have hit one on the third day; So IMHO you should need to remove all layers which are not part of the test, especially HTTP and Tomcat's session handling. When using this strategy you need long test times: you could use JUnit if you like it but would be better to avoid the inclusion in the standard test suite. It would be very nice if this could have at least "repeatable data" and performed operations (can't control exact order of course) so to use it as a reference to detect performance regressions or improvements. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-228?pag... ] Hardy Ferentschik updated HSEARCH-228: -------------------------------------- Fix Version/s: (was: 3.2.0) 3.1.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-228?pag... ] Emmanuel Bernard updated HSEARCH-228: ------------------------------------- Fix Version/s: (was: 3.2.0.Beta1) 3.2.0.Beta2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-228?pag... ] Emmanuel Bernard updated HSEARCH-228: ------------------------------------- Fix Version/s: (was: 3.3.0) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira