[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-278?pag... ] Emmanuel Bernard commented on HSEARCH-278: ------------------------------------------ I like the idea of statistics but I am not sold on this whole JMX thing. Is it worth it (not that it's a lot of work to JMXify a contract)? -- 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-278?pag... ] Sanne Grinovero commented on HSEARCH-278: ----------------------------------------- quick reminder: org.hibernate.search.backend.impl.lucene.works.LuceneWorkDelegate is defining a method which was created to plug in some counters in the future. -- 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-278?pag... ] Emmanuel Bernard commented on HSEARCH-278: ------------------------------------------ Here are some comments: - do you really need JNDI? The VM has a JMX server embedded already - I'd refactor the Lucene query to use Hibernate Search features. As it is today you do not benefit from some of our caching features like the IndexReaders. It seems that the HSearch query.getResultSize() would do the job more efficiently - What are the use cases for each HibernateSearchConfigInfo API - What I don't like about getIndexingParameters is that the toString implementation becomes part of the public API I'm quite interested in getting statistics on queries: - average / max amount of time - max / min query in String - % of time in the lucene side vs loading the objects average min / max That would be my #1 use case actually We should try and build that like the Hibernate Statistics ie expose the stats via searchFactory.getStatistics() and then consider exposing that as JMX. But in a way JMX is not as important. -- 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-278?pag... ] Hardy Ferentschik resolved HSEARCH-278. --------------------------------------- Resolution: Fixed -- 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-278?pag... ] Emmanuel Bernard commented on HSEARCH-278: ------------------------------------------ Nevermind the previous comment. I would add that under a Managment chapter though and spend as much time on stats than on JMX. Also are you linking statistics use to the JMX flag? I think there should be a separated flag, like core. -- 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