You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Otávio Gonçalves de Santana <os...@tomitribe.com> on 2017/12/27 20:08:15 UTC
Improves MDB performance with instance pool
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
Re: Improves MDB performance with instance pool
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi David,
Default should be the same no - that is what we discussed IIRC? So no need
to bump the minor IMO.
Le 23 janv. 2018 00:51, "David Blevins" <da...@gmail.com> a écrit :
From a versioning perspective, do we want to bump to 7.1?
We've just radically changed the instance management of the MDB container
and *removed* the old code. It feels off to deliver kind of a change in a
7.0.x.
The new functionality is awesome, just speaking from a change management
perspective.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Jan 19, 2018, at 1:45 AM, Thiago Veronezi <th...@veronezi.org> wrote:
>
> Thank you Otávio Santana, Ivan Junckes and Daniel Cunha!
>
> https://twitter.com/TheASF/status/954212833536884736
>
> []s,
> Thiago.
>
>
>
> On Fri, Jan 19, 2018 at 2:45 AM, Jonathan Gallimore <
> jonathan.gallimore@gmail.com> wrote:
>
>> 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" <th...@veronezi.org> 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 <th...@veronezi.org>
>>> 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 <th...@veronezi.org>
>>>> 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 <
>>>>> rmannibucau@gmail.com> 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" <
>>>>>> osantana@tomitribe.com>
>>>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
Re: Improves MDB performance with instance pool
Posted by David Blevins <da...@gmail.com>.
From a versioning perspective, do we want to bump to 7.1?
We've just radically changed the instance management of the MDB container and *removed* the old code. It feels off to deliver kind of a change in a 7.0.x.
The new functionality is awesome, just speaking from a change management perspective.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Jan 19, 2018, at 1:45 AM, Thiago Veronezi <th...@veronezi.org> wrote:
>
> Thank you Otávio Santana, Ivan Junckes and Daniel Cunha!
>
> https://twitter.com/TheASF/status/954212833536884736
>
> []s,
> Thiago.
>
>
>
> On Fri, Jan 19, 2018 at 2:45 AM, Jonathan Gallimore <
> jonathan.gallimore@gmail.com> wrote:
>
>> 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" <th...@veronezi.org> 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 <th...@veronezi.org>
>>> 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 <th...@veronezi.org>
>>>> 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 <
>>>>> rmannibucau@gmail.com> 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" <
>>>>>> osantana@tomitribe.com>
>>>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
Re: Improves MDB performance with instance pool
Posted by Thiago Veronezi <th...@veronezi.org>.
Thank you Otávio Santana, Ivan Junckes and Daniel Cunha!
https://twitter.com/TheASF/status/954212833536884736
[]s,
Thiago.
On Fri, Jan 19, 2018 at 2:45 AM, Jonathan Gallimore <
jonathan.gallimore@gmail.com> wrote:
> 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" <th...@veronezi.org> 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 <th...@veronezi.org>
> > 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 <th...@veronezi.org>
> > > 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 <
> > >> rmannibucau@gmail.com> 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" <
> > >>> osantana@tomitribe.com>
> > >>> 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
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: Improves MDB performance with instance pool
Posted by Jonathan Gallimore <jo...@gmail.com>.
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" <th...@veronezi.org> 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 <th...@veronezi.org>
> 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 <th...@veronezi.org>
> > 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 <
> >> rmannibucau@gmail.com> 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" <
> >>> osantana@tomitribe.com>
> >>> 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
> >>> >
> >>>
> >>
> >>
> >
>
Re: Improves MDB performance with instance pool
Posted by Thiago Veronezi <th...@veronezi.org>.
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 <th...@veronezi.org>
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 <th...@veronezi.org>
> 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 <
>> rmannibucau@gmail.com> 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" <
>>> osantana@tomitribe.com>
>>> 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
>>> >
>>>
>>
>>
>
Re: Improves MDB performance with instance pool
Posted by Thiago Veronezi <th...@veronezi.org>.
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 <th...@veronezi.org> 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 <rmannibucau@gmail.com
> > 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" <
>> osantana@tomitribe.com>
>> 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
>> >
>>
>
>
Re: Improves MDB performance with instance pool
Posted by Thiago Veronezi <th...@veronezi.org>.
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 <rm...@gmail.com>
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" <
> osantana@tomitribe.com>
> 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
> >
>
Re: Improves MDB performance with instance pool
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <os...@tomitribe.com>
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
>