You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Fredrik Jonson <fr...@myrealbox.com> on 2009/04/06 14:40:44 UTC

Change the MDB instance limit (UnavailableException: Only 10 instances can be created)

Hi,

I've implemented a custom inbound resource adapter (connector), and I've run
into a little snag in G 2.1.4: I can only instantiate 10 instances of the
MessageEndpoint, beyond that I get the following stacktrace in my resource
adapter:

javax.resource.spi.UnavailableException: Only 10 instances can be created
   at org.apache.openejb.core.mdb.
        MdbInstanceFactory.createInstance(MdbInstanceFactory.java:108)
   at o.a.o.core.mdb.EndpointHandler.<init>(EndpointHandler.java:79)
   at o.a.o.core.mdb.EndpointFactory.createEndpoint(EndpointFactory.java:64)
   at org.example.connector.ExampleWorker.useEndpoint(ExampleWorker.java:59)

I found a few mail threads about the instanceLimit, but sofar I've failed to
figure out what to change. 

Issue 3783[0] refers to a "Default\ MDB\ Container.InstanceLimit" that can
be overridden in the server wide config.xml, but as far as I've tried that
does not work in 2.1.4. Besides, it seems a little brutal to change it
globally, should that not preferably be controlled per resource adapter in
the geronimo-application.xml (or by MDB annotations)

As always, I'm greatful for any helping hints.

[0] https://issues.apache.org/jira/browse/GERONIMO-3783

cheers,
-- 
Fredrik Jonson


Re: Change the MDB instance limit

Posted by Fredrik Jonson <fr...@myrealbox.com>.
Ivan wrote:

>  See, I thought OpenEJB always delegates the MDB management to ActiveMQ.

True and False; it depends on how you define MDB management. ;)

It's a close relationship between the resource adapter and the EJB container.
On the "application side" of the container openejb is responsible for MDB
instantiation, resource injection and other lifecycle tasks. ActiveMQ works
on the resource adapter side, so it can request new endpoint instances (MDB)
from a factory (openejb), but it does not controll the factory itself.

>  I remeber if I set the maxsessions with 1, and throught the EJB console
>  in 2.2, I will see the MDB instance number will be 1.

Correct, that works as expected. Withouth changing openejb's InstanceLimit 
you can tell activemq to use any number of sessions between 0 and 10.

--
Fredrik Jonson


Re: Change the MDB instance limit

Posted by Ivan <xh...@gmail.com>.
See, I thought OpenEJB always delegates the MDB management to ActiveMQ.
I remeber if I set the maxsessions with 1, and throught the EJB console in
2.2, I will see the MDB instance number will be 1. No need to do more
configuration.
I will re-verify it later.
Thanks for your explaination, ^_^

2009/4/7 Fredrik Jonson <fr...@myrealbox.com>

> Ivan wrote:
>
> >  I guess that you could add the @ActivationConfigProperty(propertyName =
> >  "maxSessions", propertyValue = "100") to your MDB, so that
> >  ActiveMQEndpointWorker will allow you create more MDB instance.
>
> The thing is that I do not use ActiveMQ's resource adapter, I have my own
> custom resource adapter. As far as I understand it the maxSessions property
> is completely specific to ActiveMQ, and does not affect the OpenEJB
> configuration that I need to change.
>
> Besides, looking back on other mail thread on this list, they've needed
> (tried)
> to change both the maxSessions for activemq's connector _and_ the
> InstanceLimit
> for openejb. Changing maxSessions alone has AFAIU never changed the total
> number of instances. Could be wrong though, feel free to correct me...
>
> --
> Fredrik Jonson
>
>


-- 
Ivan

Re: Change the MDB instance limit

Posted by Fredrik Jonson <fr...@myrealbox.com>.
Ivan wrote:

>  I guess that you could add the @ActivationConfigProperty(propertyName =
>  "maxSessions", propertyValue = "100") to your MDB, so that
>  ActiveMQEndpointWorker will allow you create more MDB instance.

The thing is that I do not use ActiveMQ's resource adapter, I have my own
custom resource adapter. As far as I understand it the maxSessions property
is completely specific to ActiveMQ, and does not affect the OpenEJB
configuration that I need to change. 

Besides, looking back on other mail thread on this list, they've needed (tried)
to change both the maxSessions for activemq's connector _and_ the InstanceLimit
for openejb. Changing maxSessions alone has AFAIU never changed the total
number of instances. Could be wrong though, feel free to correct me...

--
Fredrik Jonson


Re: Change the MDB instance limit

Posted by Ivan <xh...@gmail.com>.
I guess that you could add the @ActivationConfigProperty(propertyName =
"maxSessions", propertyValue = "100") to your MDB, so that
ActiveMQEndpointWorker will allow you create more MDB instance.
Wish it helps.
          Ivan

2009/4/6 Fredrik Jonson <fr...@myrealbox.com>

> Hi again,
>
> Here's some additional info. First, the InstanceLimit configuration change
> I mentioned in the original mail was to change config.xml and replace:
>
>  <module name="org.apache.geronimo.configs/j2ee-server/2.1.4/car"/>
>
> With:
>
>  <module name="org.apache.geronimo.configs/j2ee-server/2.1.4/car">
>    <gbean name="org.apache.geronimo.configs/j2ee-server/2.1.4/car?
>      ServiceModule=org.apache.geronimo.configs/j2ee-server/2.1.4/car,
>        j2eeType=GBean,name=CustomPropertiesGBean"
>      gbeanInfo="org.apache.geronimo.system.properties.SystemProperties">
>      <attribute name="systemProperties">
>        Default\ MDB\ Container.InstanceLimit=50</attribute>
>    </gbean>
>  </module>
>
> As mentioned the above does nothing. After changing config.xml I still
> get the "Only 10 instances..." exception.
>
> Secondly, I have worked out a b*tt ugly brute force hack that actually
> solves
> the problem. Nothing for the faint of heart, but here we go:
>
>  1. Dive into
> $GERONIMO_HOME/repository/org/apache/openejb/openejb-core/3.0.1
>
>  2. Unpack the file below from openejb-core-3.0.1.jar (unzip...)
>     META-INF/org.apache.openejb.embedded/service-jar.xml
>
>  3. Edit it and change InstanceLimit from 10 to 0 (unlimited). The
> parameter
>    is only specified in one place so it is easy to find.
>
>  4. Update the openejb-core-3.0.1.jar (zip -u ...) replacing the original
>    service.xml files with the edited one.
>
>  5. Restart G.
>
> Obviously I really hope someone can help and put the above hack out of it's
> misery and guide me back on the path of proper G configuration. Thanks!
>
> --
> Fredrik Jonson
>
>


-- 
Ivan

Re: Change the MDB instance limit

Posted by Fredrik Jonson <fr...@myrealbox.com>.
Hi again,

Here's some additional info. First, the InstanceLimit configuration change
I mentioned in the original mail was to change config.xml and replace:

  <module name="org.apache.geronimo.configs/j2ee-server/2.1.4/car"/>

With:

  <module name="org.apache.geronimo.configs/j2ee-server/2.1.4/car">
    <gbean name="org.apache.geronimo.configs/j2ee-server/2.1.4/car?
      ServiceModule=org.apache.geronimo.configs/j2ee-server/2.1.4/car,
        j2eeType=GBean,name=CustomPropertiesGBean"
      gbeanInfo="org.apache.geronimo.system.properties.SystemProperties">
      <attribute name="systemProperties">
        Default\ MDB\ Container.InstanceLimit=50</attribute>
    </gbean>
  </module>

As mentioned the above does nothing. After changing config.xml I still
get the "Only 10 instances..." exception.

Secondly, I have worked out a b*tt ugly brute force hack that actually solves
the problem. Nothing for the faint of heart, but here we go:

 1. Dive into $GERONIMO_HOME/repository/org/apache/openejb/openejb-core/3.0.1

 2. Unpack the file below from openejb-core-3.0.1.jar (unzip...)
     META-INF/org.apache.openejb.embedded/service-jar.xml

 3. Edit it and change InstanceLimit from 10 to 0 (unlimited). The parameter
    is only specified in one place so it is easy to find. 

 4. Update the openejb-core-3.0.1.jar (zip -u ...) replacing the original
    service.xml files with the edited one.

 5. Restart G.

Obviously I really hope someone can help and put the above hack out of it's
misery and guide me back on the path of proper G configuration. Thanks!

-- 
Fredrik Jonson