On Mar 24, 2008, at 10:23 AM, Manu George wrote:
Did you try setting maxMessagesPerSession >= maxSessions?
maxMessagesPerSession is the prefetch size. This may work.
Anyway this is the very same error that david jencks has fixed.
https://issues.apache.org/jira/browse/GERONIMO-3783. You will need to
build and use the latest geronimo version from trunk as well as the
latest openejb and amq versions inorder to get the fix.
you will also have to update the amq and openejb versions in the
geronimo root pom to pick up your latest builds. For some reason
branches/activemq-4.1 is producing version 4.1-SNAPSHOT rather than
what I expected, 4.1.2-SNAPSHOT. I'm hoping to have the straightened
out soon as well.
thanks
david jencks
Regards
Manu
On Mon, Mar 24, 2008 at 10:43 PM, the666pack
<[EMAIL PROTECTED]> wrote:
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,
mario
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 http://activemq.apache.org/activation-spec-
properties.html. The
configurable OpenEJB properties are given here
http://openejb.apache.org/example-generated-documentation.html.
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
<[EMAIL PROTECTED]>
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:
http://www.nabble.com/MDB-performance-tuning%2C-configuration-
tp16234678s134p16234678.html
Sent from the Apache Geronimo - Users mailing list archive at
Nabble.com.
--
View this message in context: http://www.nabble.com/MDB-
performance-tuning%2C-configuration-tp16234678s134p16256383.html
Sent from the Apache Geronimo - Users mailing list archive at
Nabble.com.
