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 >> > >> > >
