9 Replies Latest reply on Apr 3, 2006 3:12 AM by Weston M. Price

    Jboss 3.2.7 JCA question.

    Madhav Inamti Novice

      We are running stress tests on our resource adapter. We have stateful EJB's calling resources on our server. We all 'remove' on EJB after we are done.

      We have run this stress test on Weblogic 8.1 for about 72 hours without any issues.

      However on Jboss 3.2.7, we see that after some time ( approx 50 mins ) we get into a situation where there are 10 ( max specified in pool) managed connections and these are not destroyed and there are no more managed connections available.

      Has anybody encountered something similar ?

      Thanks,

      mic

        • 1. Re: Jboss 3.2.7 JCA question.
          Weston M. Price Master

          I assume you are calling 'close' on your adapter. What is this RA actually doing on the back end?

          • 2. Re: Jboss 3.2.7 JCA question.
            Madhav Inamti Novice

            I am calling close on the Connection Handle and after we are done with the EJB, we are calling 'remove'.

            I have been running the same test against JBoss 4 and everything seems to be ok. However this issue with Jboss 3.2.7

            Is it that Jboss 4 is more forgiving than JBoss 3.2.7 or is it a bug in JBoss 3.2.7 ?

            -mic

            • 3. Re: Jboss 3.2.7 JCA question.
              Madhav Inamti Novice

              The answer to your other question....

              The adapter is calling COBOL programs on a COBOL server.

              -mic

              • 4. Re: Jboss 3.2.7 JCA question.
                Madhav Inamti Novice

                It seems to be trying to passivate the stateful bean and the error is

                java.io.NotSerializableException: org.jboss.resource.connectionmanager.NoTxConnectionManager$NoTxConnectionEventListener

                Why is this passivation happening ? Could it be because some "remove's" were lost ?

                -mic

                • 5. Re: Jboss 3.2.7 JCA question.
                  Madhav Inamti Novice

                  This happens on JBoss 4 too, after about 16 hours.

                  The same NotSerializable Exception and also take a look at memory consumption of Jboss classes

                  Here is the heap dump, when the passivation failure happens


                  Runtime Heap Summary
                  ====================

                  Runtime Instance List
                  ---------------------

                  Package Class Count Memory
                  ------- ----- ----- ------
                  Total 2,323,058 53,902,968
                  org.jboss.ejb StatefulSessionEnterpriseContext 232,258 (10.0%) 14,864,512 (27.6%)
                  org.jboss.ejb StatefulSessionEnterpriseContext$StatefulSessionContextImpl 232,258 (10.0%) 5,574,192 (10.3%)
                  org.jboss.resource.connectionmanager CachedConnectionManager$KeyConnectionAssociation 232,258 (10.0%) 3,716,128 (6.9%)
                  org.jboss.util.id UID 232,255 (10.0%) 5,574,120 (10.3%)
                  org.jboss.proxy ClientContainer 232,253 (10.0%) 3,716,048 (6.9%)
                  org.jboss.proxy.ejb StatefulSessionInterceptor 232,253 (10.0%) 3,716,048 (6.9%)
                  org.jboss.invocation InvocationContext 232,253 (10.0%) 3,716,048 (6.9%)
                  org.jboss.proxy SecurityInterceptor 232,253 (10.0%) 3,716,048 (6.9%)
                  org.jboss.proxy TransactionInterceptor 232,253 (10.0%) 3,716,048 (6.9%)
                  org.jboss.invocation InvokerInterceptor 232,253 (10.0%) 5,574,072 (10.3%)
                  org.jboss.net.protocol.file FileURLConnection 83 (0.0%) 2,656 (0.0%)
                  org.jboss.mx.server Invocation 83 (0.0%) 6,640 (0.0%)
                  org.jboss.deployment.scanner URLDeploymentScanner$DeployedURL 82 (0.0%) 2,624 (0.0%)
                  org.jboss.mx.server InvocationContext$NullDispatcher 82 (0.0%) 1,968 (0.0%)
                  org.jboss.resource.connectionmanager NoTxConnectionManager$NoTxConnectionEventListener 29 (0.0%) 1,624 (0.0%)
                  org.jboss.resource.connectionmanager ConnectionRecord 27 (0.0%) 648 (0.0%)
                  org.jboss.mx.loading ResourceInfo 22 (0.0%) 352 (0.0%)
                  org.jboss.logging Log4jLoggerPlugin 12 (0.0%) 192 (0.0%)
                  org.jboss.logging Logger 12 (0.0%) 192 (0.0%)
                  org.jboss.tm GlobalId 8 (0.0%) 192 (0.0%)
                  org.jboss.tm TransactionImpl 8 (0.0%) 768 (0.0%)
                  org.jboss.tm XidImpl 8 (0.0%) 320 (0.0%)
                  org.jboss.net.protocol.file FileURLLister$1 6 (0.0%) 144 (0.0%)
                  org.jboss.util.timeout TimeoutFactory$TimeoutImpl 6 (0.0%) 192 (0.0%)
                  org.jboss.mx.server.registry MBeanEntry 4 (0.0%) 128 (0.0%)
                  org.jboss.mx.server RawDynamicInvoker 4 (0.0%) 288 (0.0%)
                  org.jboss.invocation InvocationStatistics$TimeStatistic 3 (0.0%) 144 (0.0%)
                  org.jboss.invocation PayloadKey 3 (0.0%) 48 (0.0%)
                  org.jboss.net.protocol.file FileURLLister 2 (0.0%) 16 (0.0%)
                  org.jboss.net.protocol URLListerFactory 2 (0.0%) 32 (0.0%)
                  org.jboss.deployment.scanner URLDeploymentScanner$1 2 (0.0%) 32 (0.0%)
                  org.jboss.invocation MarshalledValue 2 (0.0%) 32 (0.0%)
                  org.jboss.net.protocol.resource ResourceURLConnection 1 (0.0%) 40 (0.0%)
                  org.jboss.tm LocalId 1 (0.0%) 16 (0.0%)
                  org.jboss.mx.server AbstractMBeanInvoker$OperationKey 1 (0.0%) 24 (0.0%)
                  org.jboss.security SecurityAssociation$SubjectContext 1 (0.0%) 24 (0.0%)
                  org.jboss.invocation MarshalledInvocation 1 (0.0%) 64 (0.0%)
                  org.jboss.web.tomcat.security SecurityAssociationActions$ClearAction 1 (0.0%) 8 (0.0%)
                  org.jboss.web.tomcat.security SecurityAssociationActions$PopRunAsRoleAction 1 (0.0%) 8 (0.0%)
                  org.jboss.jmx.adaptor.html HtmlAdaptorServlet 1 (0.0%) 16 (0.0%)
                  org.jboss.ejb.plugins SecurityActions$5 1 (0.0%) 16 (0.0%)
                  org.jboss.resource.connectionmanager IdleRemover 1 (0.0%) 40 (0.0%)
                  org.jboss.resource.connectionmanager InternalManagedConnectionPool$Counter 1 (0.0%) 16 (0.0%)
                  org.jboss.ejb.plugins SecurityActions$9 1 (0.0%) 8 (0.0%)
                  org.jboss.ejb.plugins SecurityActions$7 1 (0.0%) 16 (0.0%)
                  org.jboss.resource.connectionmanager IdleRemover$1 1 (0.0%) 16 (0.0%)
                  org.jboss.resource.connectionmanager InternalManagedConnectionPool 1 (0.0%) 64 (0.0%)
                  org.jboss.ejb.plugins SecurityActions$6 1 (0.0%) 16 (0.0%)
                  org.jboss.ejb.plugins SecurityActions$1 1 (0.0%) 8 (0.0%)
                  org.jboss.ejb AllowedOperationsAssociation$1 1 (0.0%) 16 (0.0%)
                  org.jboss.tm TxManager$ThreadInfo 1 (0.0%) 24 (0.0%)
                  org.jboss.metadata MethodAttributes 1 (0.0%) 24 (0.0%)
                  org.jboss.ejb.plugins SecurityActions$4 1 (0.0%) 8 (0.0%)

                  Garbage Monitor
                  ---------------

                  Package Class GC'ed Memory Released Size Alive Allocated At
                  ------- ----- ----- --------------- ---- ----- ------------
                  char[ ] 94,383,427 16,914,695,696 115,200 233,778 java.lang.StringBuffer.expandCapacity()
                  java.lang String 74,102,071 1,778,449,704 24 232,346 java.lang.StringBuffer.toString()
                  char[ ] 59,241,861 3,264,029,152 2,640 11 java.lang.StringBuffer.()
                  java.lang String 25,836,082 620,065,968 24 38 java.lang.String.substring()
                  java.nio HeapCharBuffer 19,756,587 948,316,176 48 0 java.nio.CharBuffer.wrap()
                  char[ ] 15,567,446 4,518,927,376 1,528 0 sun.nio.cs.StreamEncoder.write()
                  java.lang StringBuffer 15,559,868 373,436,832 24 0 java.text.DateFormat.format()
                  org.apache.log4j.spi LoggingEvent 15,327,545 980,962,880 64 0 org.apache.log4j.Category.forcedLog()
                  char[ ] 15,102,736 724,931,328 48 3 java.lang.StringBuffer.setLength()
                  java.lang StringBuffer 14,573,813 349,771,512 24 0 java.io.ObjectInputStream$BlockDataInputStream.readUTFBody()



                  Report Date: Apr 1, 2006 11:27:04 AM

                  • 6. Re: Jboss 3.2.7 JCA question.
                    Weston M. Price Master

                    At a quick glance, in your SFSB is the connection handle transient? It looks like when passivation occurs, it is trying to serialize your adapter.


                    • 7. Re: Jboss 3.2.7 JCA question.
                      Madhav Inamti Novice

                      I think

                      org.jboss.resource.connectionmanager.NoTxConnectionManager$NoTxConnectionEventListener

                      is not serializable.

                      We would like to solve this issue for the customer.

                      mic

                      • 8. Re: Jboss 3.2.7 JCA question.
                        Madhav Inamti Novice

                        Indeed it looks like that. the connection handle was not transient in the test code. I will make it transient so that the adapter or parts of it does not get serialized.

                        However, my question is why is passivation happening. I am calling an EJB method that calls COBOL comes back and a remove on the EJB takes place.

                        Could it be that a managed connection that was used to call COBOL was destroyed by JBOss before the remove on EJB happened ?

                        -mic

                        • 9. Re: Jboss 3.2.7 JCA question.
                          Weston M. Price Master

                          This is really now an EJB question. Submit a question in regards to passivation/activation. If I was to venture I guess, here is what I think might be happening. You may be getting timeouts/exceptions in your operations on of SFSB. In the case of an exception, you have to guarantee that the remove() operation is called (in a finally block). Something tells me that this might not be getting done. As a result, those instances remain in the pool and are subject to passivation. Then, they exception you are seeing occurs.