Thanks for this. I'll give this a test with a snapshot today. Thank you to Otávio Santana and Ivan Junckes for the contribution.
Jon On 18 Jan 2018 15:37, "Thiago Veronezi" <[email protected]> wrote: > Hi devs, > > I'm going to merge the two PRs with the MDB pooling improvements. > > https://github.com/apache/tomee/pull/117 > https://github.com/apache/tomee/pull/119 > > I think we managed to address the comments. Thank you everyone! This was a > very nice team work. > > []s, > Thiago. > > > > On Thu, Jan 4, 2018 at 12:22 PM, Thiago Veronezi <[email protected]> > wrote: > > > SvetlinZarev, > > > > thanks for you reviewing the PR man! > > > > Regarding the `Thread.interrupted();` you are commenting: I'm not sure. > > This is not new code. It's something we extracted out of the existing > > Stateless container. > > https://github.com/apache/tomee/pull/117#discussion_r159500850 > > > > I will investigate more, but if anyone has any idea of why we use this > > method, that would be awesome. > > > > Thanks! > > Thiago. > > > > > > > > On Thu, Jan 4, 2018 at 8:39 AM, Thiago Veronezi <[email protected]> > > wrote: > > > >> Guys, > >> > >> The mdb container is using the default pool 10 instances limit. The > >> stateless container has a `MaxSize` property where the user sets the max > >> number of instances the pool can hold at one time. The mdb container > has a > >> InstanceLimit property that sets the max number of mdb instances are > >> available to use at one time. > >> > >> What do you guys think about deprecating that mdb property and creating > a > >> `MinSize` and `MaxSize` properties to match the ones in the stateless > >> container? > >> > >> []s, > >> Thiago > >> > >> > >> On Wed, Dec 27, 2017 at 3:20 PM, Romain Manni-Bucau < > >> [email protected]> wrote: > >> > >>> Hi Otavio and Ivan > >>> > >>> I like the fact to extract the instance management from the container - > >>> never made sense for me to reimplement it each time. > >>> > >>> However I'd like to go further and make the instance manager a resource > >>> reference in the config we can - and avoid boolean/string config like > >>> (InstanceManager = $myMdbInstanceMgr). > >>> > >>> Last note: usePool or default impl must be false or without pooling to > >>> not > >>> breaks apps and RA not supporting it, default access/wait timeouts > should > >>> be 0 for compat and perf tuning and additional threads of the manager > >>> should be 1 max (use a global SystemInstance#components thread if not > >>> configured). Also to configure the thread pool, just reuse the builder > we > >>> have, will avoid a lot of duplicated code. > >>> > >>> Hope it helps. > >>> > >>> Le 27 déc. 2017 21:08, "Otávio Gonçalves de Santana" < > >>> [email protected]> > >>> a écrit : > >>> > >>> > Ivan Junckes and I have been working to improve performance with MDB > >>> pools. > >>> > > >>> > > >>> > This goal of this proposal is to improve performance in the > >>> message-driven > >>> > bean creation using a pool of 10 objects (default value). > >>> > The strategy is to keep these objects live so that they can be reused > >>> > instead of every time create a new one. > >>> > > >>> > I have observed that the Websphere MQ RAR does not provide pool > >>> endpoints, > >>> > and the MDB container was initially written with the assumption that > >>> most > >>> > RARs do. > >>> > > >>> > Ref: https://github.com/apache/tomee/pull/117 > >>> > > >>> > >> > >> > > >
