Default InstanceLimit on MDBs

[Fredrik Jonson <fr...@myrealbox.com>]

Hi,

I've run into a problem changing the instance limit in Geronimo[0] and
while looking into that I wonder, isn't the default instance limit of
10 for MDBs pretty arbitrary set?

What are the consequences if the default is changed to 0 (unlimited)? If
I understand correctly, the prominent use case is ActiveMQ, and they already
control the number of concurrent instances with the maxSessions parameter.

I saw a previous discussion[1] a year ago that seems to end in nothing. If
there are no technical objections I'd like to open a jira issue for this.

[0] http://thread.gmane.org/gmane.comp.java.geronimo.user/12800
[1] http://thread.gmane.org/gmane.comp.java.openejb.devel/7444 

-- 
Fredrik Jonson

Re: Default InstanceLimit on MDBs

[David Blevins <da...@visi.com>]

On Apr 8, 2009, at 12:56 AM, Fredrik Jonson wrote:

> Unfortunately 'maxSessions' is a activation property that is  
> specific to
> ActiveMQ. As far as my limited reading of the jms spec now reach -  
> I've
> not found a standard way of specifying the number of instances to
> create.
>
> On the other hand, I'd be willing to bet that all major JMS resource
> adapters implement a activation property for this. ActiveMQ has the
> maxSessions which defaults to 10, and OpenMQ has a EndpointPoolMaxSize
> which defaults to 15.

To me this seems like the most promising approach.  At least on this  
project we don't have an aversion to having enhanced support for  
pluggable things so that users have less work.  We support the various  
'give me your transaction manager' properties that all JPA  
implementations seem to have:  
hibernate.transaction.manager_lookup_class, toplink.target-server,  
eclipselink.target-server, etc.

But really maybe what we need is an @PoolSize annotation so people  
could set the value on their MDB class right next to the  
@ActivationConfig.  Then both would be set in the same place and just  
might make things easier all around.

-David

Re: Default InstanceLimit on MDBs

[Fredrik Jonson <fr...@myrealbox.com>]

David Blevins wrote:

>  I wonder if there's some sneaky way we can get the maxSessions number
>  from ActiveMQ and set the pool size to be the same: or alternatively
>  setting it to unlimited if activemq is the resource adapter, though I
>  hope there is no equivalent 'unlimited' setting for the maxSessions.

ActiveMQ has the default value for maxSessions set to 10.
http://activemq.apache.org/activation-spec-properties.html

Unfortunately 'maxSessions' is a activation property that is specific to
ActiveMQ. As far as my limited reading of the jms spec now reach - I've
not found a standard way of specifying the number of instances to
create.

On the other hand, I'd be willing to bet that all major JMS resource
adapters implement a activation property for this. ActiveMQ has the
maxSessions which defaults to 10, and OpenMQ has a EndpointPoolMaxSize
which defaults to 15.
 
>  Not sure how we'd actually implement that in Geronimo -- i.e.
>  detecting which resource adapter implementation is being used.

I'd avoid that route as it requires intimate knowledge of the resource
adapters. If openejb make a special case of ActiveMQ my original use
case, a custom resource adapter, would still be exposed to the default
instance limit.

Perhaps it would be possible to make the instance limit configurable per
MDB in openejb-jar.xml? I'm not sure when the MdbInstanceFactory is
created, but if it is created on demand when openejb-jar.xml is parsed
that would be a possibility.

Maybe the right thing to do is for G to set up a server-jar.xml of their
own, that overrides the default instance limit, instead of using the
default server-jar.xml that is included in openejb-core.jar?

-- 
Fredrik Jonson 

Re: Default InstanceLimit on MDBs

[David Blevins <da...@visi.com>]

I wonder if there's some sneaky way we can get the maxSessions number  
from ActiveMQ and set the pool size to be the same: or alternatively  
setting it to unlimited if activemq is the resource adapter, though I  
hope there is no equivalent 'unlimited' setting for the maxSessions.

Not sure how we'd actually implement that in Geronimo -- i.e.  
detecting which resource adapter implementation is being used.

David Jencks, any ideas?

-David

On Apr 7, 2009, at 4:06 AM, Bharath Ganesh wrote:

> Personally, I don't thing the EJB container should default the MDB  
> pool size
> to unlimited. The EJB container would be completely agnostic of the  
> message
> broker configuration(maxSessions in case of ActiveMQ) and would need  
> the
> throttle to be setup itself, without assuming the provider  
> configuration.
> Any thoughts?
>
> On Tue, Apr 7, 2009 at 2:50 PM, Fredrik Jonson  
> <fr...@myrealbox.com>wrote:
>
>> Hi,
>>
>> I've run into a problem changing the instance limit in Geronimo[0]  
>> and
>> while looking into that I wonder, isn't the default instance limit of
>> 10 for MDBs pretty arbitrary set?
>>
>> What are the consequences if the default is changed to 0  
>> (unlimited)? If
>> I understand correctly, the prominent use case is ActiveMQ, and they
>> already
>> control the number of concurrent instances with the maxSessions  
>> parameter.
>>
>> I saw a previous discussion[1] a year ago that seems to end in  
>> nothing. If
>> there are no technical objections I'd like to open a jira issue for  
>> this.
>>
>> [0] http://thread.gmane.org/gmane.comp.java.geronimo.user/12800
>> [1] http://thread.gmane.org/gmane.comp.java.openejb.devel/7444
>>
>> --
>> Fredrik Jonson
>>
>>

Re: Default InstanceLimit on MDBs

[Fredrik Jonson <fr...@myrealbox.com>]

Bharath Ganesh wrote:

>  Personally, I don't thing the EJB container should default the MDB
>  pool size to unlimited. The EJB container would be completely
>  agnostic of the message broker configuration(maxSessions in case of
>  ActiveMQ) and would need the throttle to be setup itself, without
>  assuming the provider configuration.

My question is why the ejb container needs to assume that it has to
limit the instances by default? Apart from resource management being a
big deal in JEE in general.

I agree completely that the ejb container should be agnostic of intimate
knowledge of the resource adapter. You've certainly got a point there.
But isn't it rather safe to assume that the ra has a legitimate reason
for requesting a new endpoint when it does? Even if that happens to be
the eleventh one for a particular MDB?

Disregarding the case when a rouge ra starves the system, is anyone
aware of a ra implementation that as a default will continue requesting
endpoints for a MDB until it gets a UnavailableException? Obviously I
recognize that I'm not intimate with all the details of JEE yet, so it
could very well be a legitimate design pattern. 

--
Fredrik Jonson

Re: Default InstanceLimit on MDBs

[Bharath Ganesh <bh...@apache.org>]

Personally, I don't thing the EJB container should default the MDB pool size
to unlimited. The EJB container would be completely agnostic of the message
broker configuration(maxSessions in case of ActiveMQ) and would need the
throttle to be setup itself, without assuming the provider configuration.
Any thoughts?

On Tue, Apr 7, 2009 at 2:50 PM, Fredrik Jonson <fr...@myrealbox.com>wrote:

> Hi,
>
> I've run into a problem changing the instance limit in Geronimo[0] and
> while looking into that I wonder, isn't the default instance limit of
> 10 for MDBs pretty arbitrary set?
>
> What are the consequences if the default is changed to 0 (unlimited)? If
> I understand correctly, the prominent use case is ActiveMQ, and they
> already
> control the number of concurrent instances with the maxSessions parameter.
>
> I saw a previous discussion[1] a year ago that seems to end in nothing. If
> there are no technical objections I'd like to open a jira issue for this.
>
> [0] http://thread.gmane.org/gmane.comp.java.geronimo.user/12800
> [1] http://thread.gmane.org/gmane.comp.java.openejb.devel/7444
>
> --
> Fredrik Jonson
>
>