geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From the666pack <>
Subject Re: MDB performance tuning, configuration
Date Mon, 24 Mar 2008 17:13:09 GMT

so sorry for the 1000 messages today.. just want to add something to this
topic once more:

i have my server up now again with the old behaviour (2.0.2):

mdbs get queued up til some point the performance increases (65 concurrent
users - transactions per second about 85 transactions/sec) then the
performance decreases again. in the end of my test i have to wait another 2
minutes til the messages in the queue are finished at the server.

your proposal:

the problem i have is that when i include the activation config as you told
me to do, like:

@MessageDriven(activationConfig = {
        @ActivationConfigProperty(propertyName = "destinationType",
                                  propertyValue = "javax.jms.Queue"),
        @ActivationConfigProperty(propertyName = "maxSessions",
          propertyValue = "32"),
        @ActivationConfigProperty(propertyName = "destination",
        propertyValue = "queue/videoupdate")})

the MDB stops delivering after some time and then i have the problem i
already mentioned above: 

somehow there seem to be messages hanging in the queue and anytime i start
the server some more 10 messages are processed. but i cannot send messages
anymore to the server because it just works on some old "orphaned" messages
from the test-run before. the only solution i got from that point on is to
start with a fresh clean server as i dont knwo how to flush the queue or
something similar.

if i on the other hand dont change the "maxSessions" activation config and
just set the "MDB Container InstanceLimit" to "0" no significant performance
increase is experienced.

if someone can help more with this error i get i would be very happy.

thanks a lot in advance,


the666pack wrote:
> ok as it is just a test server i had a quick "setup session" and got a
> clean server again. i hope i dont run into the problem anymore now.. i
> will keep some backup server just in case ;)
> the666pack wrote:
>> hallo,
>> it seems i completely messed up with my MDB application now. i tried the
>> "activation spec" that you mentioned and it worked fine. then i thought
>> ia lso try to set the InstanceLimit to 0. so i went to the config.xml
>> file and changed the "MDB\ Container\ InstanceLimit=0" wrong thing to do.
>> after that i did not receive the wanted updates anymore in the database.
>> i increased the value again to "maxPool" size.. and since that at startup
>> of the server or at deploy time i always realize that some messages are
>> delivered but then it stops again. i dont even send messages anymore, the
>> messages that are delivered are from a test 2 hours ago!
>> i also tried to restart the database, restart the server, computer,
>> everything. and tried to start with an empty db. the only thing i realize
>> is that at startup or deploytime of my application it sends some 10
>> messages to the queue and after this it stops.
>> by the way.. i already set the values back to their initial state.. but
>> no effect.. i keep having this error and not possible to deliver any new
>> messages.. just everytime i start i see more 10 values being changed in
>> the database.
>> can anyone help me, please.
>> thanks,
>> mario
>> manucet wrote:
>>> You may have tried this out but increasing the maxMessagesPerSession
>>> activation config property will increase the prefetch size and
>>> generally speed it up a bit more. I assume u have already increased
>>> the maxSessions activation config property to increase the no of
>>> parallel Mdb instances. Here is a link for the properties that AMQ
>>> allows The
>>> configurable OpenEJB properties are given here
>>> Try setting the InstanceLimit property of the MdbContainer to 0 so
>>> that the no of instances created matches the no of AMQ sessions
>>> available. For setting this you need to set this as a system property.
>>> The property should be containerId.InstanceLimit where containerId is
>>> of the format  <artifactId>.<Resource Group Name>-<listener interface>
>>> eg: org.apache.geronimo.configs/activemq-ra/2.2-SNAPSHOT/car.ActiveMQ
>>> RA-javax.jms.MessageListener
>>> ie <artifactId> =  artifactId of the jms RA
>>> <Resource Group Name> - The resource Group name u gave while creating
>>> the RA
>>> <listener interface> - javax.jms.MessageListener in this case
>>> So the property in this case can be set as
>>> org.apache.geronimo.configs/activemq-ra/2.2-SNAPSHOT/car.ActiveMQ\
>>> RA-javax.jms.MessageListener.InstanceLimit=0
>>> Regards
>>> Manu
>>> On Sun, Mar 23, 2008 at 4:49 PM, the666pack <>
>>> wrote:
>>>>  hello,
>>>>  i am trying to test the performance of geronimo under load for message
>>>>  driven beans. the observed behaviour is that i get a maximum of about
>>>> 85
>>>>  transactions per second. after this, tested with about 60 concurrent
>>>> users,
>>>>  the performance drops again to about 45 tps. i hoped to increase the
>>>>  performance somehow.. things i already tried:
>>>>  -increase the mdb pool size
>>>>  -increase the thread pool size
>>>>  -increase the connector-thread-pool-size
>>>>  unfortunately nothing helped, the performance situation remains the
>>>> same.
>>>>  another observed behaviour is that in the time of silence between
>>>> tests the
>>>>  server needs some time to fulfill the requests sent before. so i see
>>>> it is
>>>>  still working although i am not sending mdb-requests anymore.
>>>>  i suppose these are the requests that are still in the queue and have
>>>> to be
>>>>  finished. i think this is the reason for the performance drop with
>>>> more
>>>>  concurrent users. i would like to see it perform without this
>>>>  "aftertime-working" and handle the requests "in time".
>>>>  maybe someone can give me a hint which other values could be important
>>>> to
>>>>  change for the performance of mdbs getting real good. i thank you very
>>>> much
>>>>  for your help,
>>>>  greetings,
>>>>  mario
>>>>  --
>>>>  View this message in context:
>>>>  Sent from the Apache Geronimo - Users mailing list archive at

View this message in context:
Sent from the Apache Geronimo - Users mailing list archive at

View raw message