8 Replies Latest reply on Jun 5, 2003 11:07 AM by Adrian Brock

    Lifecycle of EJBs

    Sven Baumgarten Newbie

      Hello,

      I use JBoss 3.2.1. I have a java client for importing data from XML. This client frequently reads data from a file and calls an "create" method of a stateless session bean and the session bean finally creates the entities. When the client starts the memory used by java.exe (running jboss) increases quickly up to about 500 MB. Then everything is getting slowly. After the client is diconnected ftom the server the CPU use of jboss is getting nearly zero and memory in use is fixed at the last level. Apparently there have been created a lot of entity bean instances.

      When will these entity beans removed from the server so that the memory will be released?

      Is there any tool for monitoring bean containers?

        • 1. Re: Lifecycle of EJBs
          Adrian Brock Master

          Depends upon your cache configuration.
          See standardjboss.xml for the default values.

          Regards,
          Adrian

          • 2. Re: Lifecycle of EJBs
            Sven Baumgarten Newbie

            Hi Adrian,

            I use the "Standard CMP 2.x EntityBean" configuration for entity beans. I tried several setups for "cache-policy-conf" but I can't realize any differences. After calling about 4000 create-methods jboss seems getting dead. Can you suggest a container configuration for little number of clients and much data reading/writing?

            Thanks
            Sven

            • 3. Re: Lifecycle of EJBs
              Adrian Brock Master

              What do you mean everything is getting slow?

              Is your disk thrashing?
              If that is the case, you are suffering from a lot
              of paging of memory to disk and vice versa.

              What memory settings do you have for the VM,
              how much memory is available.

              Regards,
              Adrian

              • 4. Re: Lifecycle of EJBs
                Sven Baumgarten Newbie

                Hi,

                I've made some tests. The client is reading data from a xml file transform it to a business object (build a DTO (data transfer object)) and calls a write-method of a stateless session bean. The session bean "writes" the content of the DTO to the entity beans. Each business object is written in 4 entity beans, the main bean and 3 one to one related sub entities (this (table) separation is done because of page size restrictions of the database). There are about 16.000 business object to write and it is done frequently by always the same method calls.

                1 Test:

                PIV, 1CPU 1,8GHz, 512MB RAM, "set JAVA_OPTS=%JAVA_OPTS% -server -Xms128m -Xmx256m"


                - JBoss starts with memory in use 90.000kb. Speed is about 1000 business objects per minute
                - memory in use reaches 310.000kb. Speed decreases to about 100 business objects per minute
                - a little bit later -> OutOfMemory


                2 Test:

                PIV, 1CPU 1,8GHz, 512MB RAM, "set JAVA_OPTS=%JAVA_OPTS% -server -Xms128m -Xmx512m"


                - JBoss starts with memory in use 90.000kb. Speed is about 600 business objects per minute.
                - memory in use reaches 200.000kb. Speed increases to about 900 business objects per minute. About 1000 business objects are written.
                - memory in use reaches 300.000kb. Speed increases to about 1200 business objects per minute. About 2500 business objects are written.
                - memory in use reaches 480.000kb. Speed decreases under 100 business objects per minute. About 5500 business objects are written.
                - memory in use oscillates between 60.000kb and 480.000kb and CPU use is nearly zero
                - 2 minutes later there was no further business object written -> test aborted.


                2 Test:

                Athlon, 2 CPU 2GHz, 1024MB RAM, "set JAVA_OPTS=%JAVA_OPTS% -server -Xms128m -Xmx512m"


                - JBoss starts with memory in use 90.000kb. Speed is about 1300 business objects per minute.
                - memory in use reaches 180.000kb. Speed increases to about 1700 business objects per minute. About 1500 business objects are written.
                - memory in use reaches 330.000kb. Speed increases to about 1900 business objects per minute. About 5000 business objects are written.
                - memory in use reaches 570.000kb. Speed decreases to about 100 business objects per minute. About 10000 business objects are written.
                - memory in use did not change anymore
                - after about 11000 business objects are written -> OutOfMemory




                I think the problem is the permanently growing memory in use. Most tasks in my application don't need data records/entity beans very long. After transaction is completed they could be discarded (their values) because before next use they must be reloaded from database. Especially in the tests above there is no need to cache the entities.

                I hope this information is a little bit useful for you

                Regards,
                Sven

                • 5. Re: Lifecycle of EJBs
                  Adrian Brock Master

                  Use commit option C then.

                  Regards,
                  Adrian

                  • 6. Re: Lifecycle of EJBs
                    Sven Baumgarten Newbie

                    J changed from commit option B to C.

                    Now I get a lot of "Unable to passivate due to ctx lock ..." messages like this (from server.log):

                    2003-06-05 14:40:38,422 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.Projekt.findByNr] Executing SQL: SELECT ...

                    2003-06-05 14:40:38,422 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.Projekt] Executing SQL: SELECT ...

                    2003-06-05 14:40:38,422 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.Gpartner.findByNr] Executing SQL: SELECT ...

                    2003-06-05 14:40:38,422 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCFindByPrimaryKeyQuery.Projekt.findByPrimaryKey] Executing SQL: SELECT ...

                    2003-06-05 14:40:38,438 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.Gpartner.findByNr] Executing SQL: SELECT ...

                    2003-06-05 14:40:38,438 WARN [org.jboss.ejb.plugins.AbstractInstanceCache] Unable to passivate due to ctx lock, id=76

                    • 7. Re: Lifecycle of EJBs
                      Sven Baumgarten Newbie

                      I changed from commit option B to C.

                      Now I get a lot of "Unable to passivate due to ctx lock ..." messages like this (from server.log):

                      2003-06-05 14:40:38,422 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.Projekt.findByNr] Executing SQL: SELECT ...

                      2003-06-05 14:40:38,422 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.Projekt] Executing SQL: SELECT ...

                      2003-06-05 14:40:38,422 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.Gpartner.findByNr] Executing SQL: SELECT ...

                      2003-06-05 14:40:38,422 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCFindByPrimaryKeyQuery.Projekt.findByPrimaryKey] Executing SQL: SELECT ...

                      2003-06-05 14:40:38,438 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.Gpartner.findByNr] Executing SQL: SELECT ...

                      2003-06-05 14:40:38,438 WARN [org.jboss.ejb.plugins.AbstractInstanceCache] Unable to passivate due to ctx lock, id=76

                      • 8. Re: Lifecycle of EJBs
                        Adrian Brock Master

                        That is a know problem.

                        In JBoss3.0 we didn't return the bean the pool
                        at all. In 3.2 we try to, but only when we
                        are positive it is not being used.

                        Report it as a bug, it is something that needs
                        sorting out. The only ill affect is that the pool
                        is not used as efficiently as it could be.

                        Regards,
                        Adrian