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-tp16234678s134p16249640.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
