Announcement Announcement Module
Collapse
No announcement yet.
ApplicationContext never cleanup with EJB Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • ApplicationContext never cleanup with EJB

    Hi everybody,


    I'm currently working with ContextSingletonBeanFactoryLocator with my EJB to share my Spring application context through all my EJBs to make sure all my bean are really singleton. Everything works well eept when I get a runtime exception (I'm currently in development process not ready to go in prod), after the exception has been throwed and handle by the EJB container, it looks like another application context is initialized and first is never destroy creating memory leak on my server, I dump my memory after the exception and I'm able to see many instance of all the bean's classes in memory (look class loader never release previous class loaded and reload new instance in memory).

    After some time, I got an OutOfMemoryException exception from my server and I can see many instance of my supposed singleton object in the dump of memory.

    I'm using WAS 6.0.

    Is it a way to make sure my application context will be correctly free in my server whether an exception occured or not ?

  • #2
    Does your EJB subclass AbstractStatelessSessionBean?

    Comment


    • #3
      Originally posted by wpoitras
      Does your EJB subclass AbstractStatelessSessionBean?
      Yes, and I also have a MDB that subclass the AbstractMessageDrivenBean...

      I overwrite the setSessionContext to set the ContextSingletonBeanFactoryLocator instance as explained in the documentation, after that I'm using getBeanFactory in the onEjbCreate method to get my bean...do I need instead to work with useBean call on ContextSingletonBeanFactoryLocator ?

      Comment


      • #4
        No. getBeanFactory().getBean is the right way to go. The application context shouldn't get destroyed unless the last EJB is being destroyed before any other ones are created causing the application context's reference count to drop to 0. Having you turned on debug logging?

        Comment


        • #5
          ApplicationContext never cleanup with EJB

          But is it normal to have another applicationContext created in case of an runtime exception? Debug logging - you mean in our application ?

          Comment


          • #6
            I'm specifically talking about logging for Spring (which uses Apache Commons logging).

            It actually shouldn't be normal to create another application context because you are using ContextSingletonBeanFactoryLocator which uses reference counting to only create a new application context if it doesn't exist previously, and to destroy it once all references to the appliation context are released.

            Comment


            • #7
              No I didnt enable spring logging, I can, anything perticular I be looking for?

              Comment


              • #8
                To check ApplicationContext, you can write a simple bean and check for event ("ConextRefreshedEvent"). what is does, event published when the ApplicationContext is intialized or refereshed. Initialized here means that all beans are loaded, singletons are pre-instantiated and the ApplicationContext is redy for use.

                Comment

                Working...
                X