Re: [hibernate-dev] exposing statistics easier (HHH-3593 solution)

2008-11-21 Thread Steve Ebersole
Its actually in 3.3 already as well - Steve Ebersole Project Lead http://hibernate.org [EMAIL PROTECTED] Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com [EMAIL PROTECTED] [EMAIL PROTECTED] On Fri, 2008-11-21 at 09:26 +0100, Max Rydahl Andersen wrot

Re: [hibernate-dev] [Search] making updates to the indexes concurrently

2008-11-21 Thread Hardy Ferentschik
On Fri, 21 Nov 2008 14:46:14 +0100, Sanne Grinovero <[EMAIL PROTECTED]> wrote: about the size = If so we need two settings I believe since the default size of these two different thread pools will be different, right? yes you got the point, this is why I'm writing here. Actually the s

Re: [hibernate-dev] Re: [Search] making updates to the indexes concurrently

2008-11-21 Thread Sanne Grinovero
2008/11/21 Hardy Ferentschik <[EMAIL PROTECTED]>: > On Fri, 21 Nov 2008 00:58:53 +0100, Sanne Grinovero > <[EMAIL PROTECTED]> wrote: > >> I think the best option would be to have a separate >> Executor for each directory provider: otherwise it could happen >> that a slowly reacting index could bloc

Re: [hibernate-dev] [Search] making updates to the indexes concurrently

2008-11-21 Thread Sanne Grinovero
inline answers; 2008/11/21 Hardy Ferentschik <[EMAIL PROTECTED]>: > On Thu, 20 Nov 2008 21:14:16 +0100, Sanne Grinovero > <[EMAIL PROTECTED]> wrote: > >> because of HSEARCH-268( optimize indexes in parallel ) but also for >> other purposes, I am in need to define a new ThreadPool in Hibernate >> S

Re: [hibernate-dev] Re: [Search] making updates to the indexes concurrently

2008-11-21 Thread Hardy Ferentschik
On Fri, 21 Nov 2008 00:58:53 +0100, Sanne Grinovero <[EMAIL PROTECTED]> wrote: I think the best option would be to have a separate Executor for each directory provider: otherwise it could happen that a slowly reacting index could block correct operation from others, as many queues could pileup

Re: [hibernate-dev] [Search] making updates to the indexes concurrently

2008-11-21 Thread Hardy Ferentschik
On Thu, 20 Nov 2008 21:14:16 +0100, Sanne Grinovero <[EMAIL PROTECTED]> wrote: because of HSEARCH-268( optimize indexes in parallel ) but also for other purposes, I am in need to define a new ThreadPool in Hibernate Search's Lucene backend. The final effect will actually be that all changes to

Re: [hibernate-dev] exposing statistics easier (HHH-3593 solution)

2008-11-21 Thread Max Rydahl Andersen
Next major release of Hibernate will be much more modularized than earlier. It's in trunk, so not something that is going to show up in 3.2.x. -max hibernate-jmx is actually news to me - I didn't realize there was such a module. Is it easy for someone with an existing app to plop this hiber

Re: [hibernate-dev] exposing statistics easier (HHH-3593 solution)

2008-11-21 Thread John Mazzitelli
hibernate-jmx is actually news to me - I didn't realize there was such a module. Is it easy for someone with an existing app to plop this hibernate-jmx module (.jar?) in their app deployment and have it "just work"? I'm curious if this is going to be shipped with, say, JBossAS, so its alread

Re: [hibernate-dev] exposing statistics easier (HHH-3593 solution)

2008-11-21 Thread John Mazzitelli
That's saying "use the platform MBeanServer" *and* "use the MBeanServer with a default domain name of "my_mbean_server". Which takes effect? I didn't want someone to do something confusing like this. I understand. But we can raise a config exception and fail fast. With your approach, if I nam

Re: [hibernate-dev] exposing statistics easier (HHH-3593 solution)

2008-11-21 Thread Max Rydahl Andersen
John, follow Steve's lead and put it in hibernate-jmx module. These statistics have been hidden all too long for users of Hibernate IMO. This setting will make it available. IMO it is not a security issue since its not enabled by default and similar to users of AS can go enable jmx console witho