13 Replies Latest reply on Jan 21, 2012 7:57 PM by mick_mcgovern1

    Local EJB binding in AS 6

    mick_mcgovern1

      Hi,

       

      In JBoss 4.2.3 I found local EJBs at "earname/ejbname/local".

       

      Doesn't find them in AS 6. Anyone know where I can find them?

       

      Thanks

       

      Michael

        • 1. Local EJB binding in AS 6
          jaikiran

          That hasn't changed in AS6. How are you packaging your EJBs? Are they annotated or via ejb-jar.xml? A bit more details about the problem will help figure out the issue.

          • 2. Local EJB binding in AS 6
            mick_mcgovern1

            Thanks.

             

            Using annotations. The packaging is the same as I'm doing for 4.2.3 where it works fine - the JNDI lookup code hasn't changed either.

             

            AS6 complains that the "earname" is not bound - but I'll take another closer look at the stack traces.

            • 3. Local EJB binding in AS 6
              mick_mcgovern1

              I'm wondering if it related to the repalcement of the 4.2.3 jboss-app.xml that I have as follows in 4.2.3:

               

              <jboss-app>

              <loader-repository>

                  capital:app=ejb3

                </loader-repository>

              </jboss-app>

               

              capital is the earname.

               

              I've put the same content into the jboss.xml file for AS 6 because I assumed this replaced the jboss-app.xml from 4.2.3.

               

              <jboss xmlns="http://www.jboss.com/xml/ns/javaee"

                           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

                           xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee

                                          http://www.jboss.org/j2ee/schema/jboss_5_1.xsd"

                           version="5.1">

                  <loader-repository>

                  capital:app=ejb3

                </loader-repository>

              </jboss>

              • 4. Local EJB binding in AS 6
                ebross

                Hi Michael McGovern,

                 

                ”earname not bound”

                 

                I would suggest that you check  your jndi in http://localhost:8080/jmx-console : In the list, do you see “earname/ejbImplementionClassName/local” ?

                 

                Check, particularly, that the “earname” is your true earFilenameWithoutTheExtention.

                 

                 

                Also, if you are using the mapping param in @EJB as in:

                 

                @EJB(mappedName="earname/ClassName/local")

                 

                Remove it or make sure that they are same as the one in http://localhost:8080/jmx-console .

                 

                Please note that “jboss-app.xml” and  “jboss.xml” serve different purposes. jboss.xml is used for configuring EJB, including jndi,  whereas jboss-app.xml is used for configuring class loader, ear deployment etc. Both are proprietary deployment descriptors.

                 

                Beside, I don't think the ”earname not bound” problem is a class-loading problem, hence moving your “loader-repository” wouldn't solve the problem.

                • 5. Local EJB binding in AS 6
                  mick_mcgovern1

                  Thanks.

                   

                  I found the JNDI lookup failure was in the constructor of one of the web service impl classes. Perhaps the JNDI context is not fully setup at that point in the load? I made the lookups lazy so they aren't loaded in the constructor. This got me past the current problem but I think I'm now stuck with the problem I had when I tried to deploy this app to 5.1.0.

                   

                  http://community.jboss.org/thread/155047

                   

                  This problem was never solved hence why I'm still using 4.2.3.

                   

                  The app goes into a loop - it was stuck at 100% CPU for 30 minutes before I killed it. Just like 5.1.0 was doing though I haven't gone through debug to prove it's stuck in the same code.

                  • 6. Local EJB binding in AS 6
                    jaikiran

                    Michael McGovern wrote:

                     

                    Thanks.

                     

                    I found the JNDI lookup failure was in the constructor of one of the web service impl classes. Perhaps the JNDI context is not fully setup at that point in the load?

                     

                    You shouldn't be doing JNDI lookups in the constructor. Instead try doing it in the lifecycle callback methods (like @PostConstruct).

                    • 7. Local EJB binding in AS 6
                      jaikiran

                      Michael McGovern wrote:

                       

                      This got me past the current problem but I think I'm now stuck with the problem I had when I tried to deploy this app to 5.1.0.

                       

                      http://community.jboss.org/thread/155047

                       

                      The class in that stacktrace, in that other thread, is non-existent in JBoss AS 6.0.0.Final. So it certainly isn't that issue.

                       

                       

                      Michael McGovern wrote:

                       

                      The app goes into a loop - it was stuck at 100% CPU for 30 minutes before I killed it. Just like 5.1.0 was doing though I haven't gone through debug to prove it's stuck in the same code.

                       

                      Please provide more details including any relevant details about your application packaging.

                      • 8. Re: Local EJB binding in AS 6
                        mick_mcgovern1

                        Thanks,

                         

                        Yes moving the lookup out of constructor helped. I guess 4.2.3's different web service impl didn't instantiate an instance of the EJB during the boot phase.

                         

                        Regarding the loop I'm now getting - I can only run it using the run.bat (not from Eclipse) - Is there a way to force a stack trace dump from Windows? Or perhaps still launch from run.bat but with some debug settings and then get Eclipse to attach to it and pause it when it gets into the loop?

                        • 9. Local EJB binding in AS 6
                          mick_mcgovern1

                          Hi,

                           

                          Here is the stack trace for AS 6. Very similar up to a point (BeanMetaDataDeployer.deploy), the code is processing different beans on eash suspend of the thread but whether or not it is looping or just extremely slow at progressing through the several hundread SFSB I can't say for sure. What took 8 minutes to boot in 4.2.3 is still going after an hour on 6. Perhaps there is some sort of cyclical dependency? I will do some trial and error to reduce the number of SFSB in the EAR, seeing if a reduced number boots and then re-adding until it breaks again.

                           

                          AS 6.0.0 final  - stack trace during "loop"

                           

                          ObjectName.construct(String) line: 467   

                          ObjectName.<init>(String) line: 1403   

                          ObjectName.getInstance(String) line: 1285   

                          JMXObjectNameFix.needsAnAlias(Object) line: 51   

                          AbstractDependencyItem.setIDependOn(Object) line: 277   

                          AbstractDependencyItem.<init>(Object, Object, ControllerState, ControllerState) line: 87   

                          AbstractInjectionValueMetaData(AbstractDependencyValueMetaData).initialVisit(MetaDataVisitor) line: 369   

                          AbstractInjectionValueMetaData.initialVisit(MetaDataVisitor) line: 340   

                          PreprocessMetaDataVisitor(AbstractMetaDataVisitor).internalInitialVisit(MetaDataVisitorNode) line: 111   

                          PreprocessMetaDataVisitor(AbstractMetaDataVisitor).initialVisit(MetaDataVisitorNode) line: 74   

                          AbstractPropertyMetaData(AbstractFeatureMetaData).initialVisit(MetaDataVisitor) line: 101   

                          AbstractPropertyMetaData.initialVisit(MetaDataVisitor) line: 287   

                          PreprocessMetaDataVisitor(AbstractMetaDataVisitor).internalInitialVisit(MetaDataVisitorNode) line: 111   

                          PreprocessMetaDataVisitor(AbstractMetaDataVisitor).initialVisit(MetaDataVisitorNode) line: 74   

                          AbstractBeanMetaData(AbstractFeatureMetaData).initialVisit(MetaDataVisitor) line: 101   

                          AbstractBeanMetaData.initialVisit(MetaDataVisitor) line: 686   

                          PreprocessMetaDataVisitor.run() line: 53   

                          AccessController.doPrivileged(PrivilegedAction<T>) line: not available [native method]   

                          AbstractKernelControllerContext.preprocessMetaData() line: 233   

                          AbstractKernelControllerContext.setController(Controller) line: 199   

                          AbstractKernelController(AbstractController).install(ControllerContext, boolean) line: 855   

                          AbstractKernelController(AbstractController).install(ControllerContext) line: 641   

                          BeanMetaDataDeployer.deploy(DeploymentUnit, BeanMetaData) line: 182   

                          BeanMetaDataDeployer.deploy(DeploymentUnit, Object) line: 58   

                          BeanMetaDataDeployer(AbstractSimpleRealDeployer<T>).internalDeploy(DeploymentUnit) line: 62   

                          BeanMetaDataDeployer(AbstractRealDeployer).deploy(DeploymentUnit) line: 55   

                          DeployerWrapper.deploy(DeploymentUnit) line: 179   

                          DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1832   

                          DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1550   

                          DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1571   

                          DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1603   

                          DeployersImpl.install(ControllerContext, ControllerState, ControllerState) line: 1491   

                          DeploymentControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 379   

                          AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 2044   

                          AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 1083   

                          AbstractKernelController(AbstractController).executeOrIncrementStateDirectly(ControllerContext, boolean) line: 1322   

                          AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1246   

                          AbstractKernelController(AbstractController).resolveContexts(boolean) line: 1139   

                          AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 939   

                          AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 654   

                          DeployersImpl.change(DeploymentControllerContext, ControllerState, boolean) line: 1983   

                          DeployersImpl.process(List<DeploymentContext>, List<DeploymentContext>) line: 1076   

                          MainDeployerImpl.process() line: 679   

                          MainDeployerPlugin.process() line: 106   

                          ProfileControllerContext$DelegateDeployer.process() line: 143   

                          ProfileDeployAction.deploy(Profile, ManagedProfileDeployer, boolean) line: 151   

                          ProfileDeployAction.installActionInternal(KernelControllerContext) line: 94   

                          ProfileDeployAction(InstallsAwareAction).installAction(KernelControllerContext) line: 54   

                          ProfileDeployAction(InstallsAwareAction).installAction(ControllerContext) line: 42   

                          ProfileDeployAction(SimpleControllerContextAction<T>).simpleInstallAction(T) line: 62   

                          ProfileDeployAction(AccessControllerContextAction<S,T>).install(ControllerContext) line: 71   

                          ProfileControllerContextActions(AbstractControllerContextActions).install(ControllerContext, ControllerState, ControllerState) line: 51   

                          ProfileControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 379   

                          AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 2044   

                          AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 1083   

                          AbstractKernelController(AbstractController).executeOrIncrementStateDirectly(ControllerContext, boolean) line: 1322   

                          AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1246   

                          AbstractKernelController(AbstractController).resolveContexts(boolean) line: 1139   

                          AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 939   

                          AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 654   

                          ProfileActivationWrapper$BasicProfileActivation.start() line: 190   

                          ProfileActivationWrapper.start() line: 87   

                          ProfileActivationService.activateProfile(String) line: 215   

                          ProfileActivationService.activate(ProfileKey) line: 159   

                          BasicProfileServiceBootstrap<K,T>(AbstractProfileServiceBootstrap).activate(ProfileMetaDataContext) line: 112   

                          BasicResolverFactory$ProfileResolverFacade.deploy() line: 87   

                          BasicProfileServiceBootstrap<K,T>(AbstractProfileServiceBootstrap).start(AbstractDomainMetaData) line: 91   

                          BasicProfileServiceBootstrap<K,T>.start(K) line: 132   

                          BasicProfileServiceBootstrap<K,T>.start(Server) line: 56   

                          JBossASServerImpl(AbstractServer<K,T>).startBootstraps() line: 827   

                          AbstractServer$StartServerTask.run() line: 417   

                          Thread.run() line: 619   

                           

                           

                          Data

                           

                          ObjectName:  "org.jboss.ejb.bean.instantiator/Capital/beans/ForceLogoff" (id=2996)   

                           

                           

                           

                           

                          Suspend Again:

                           

                          ObjectName: org.jboss.ejb.bean.instantiator/Capital/beans/ResetExternalUser

                           

                          Capital is the EAR, beans is the EJB JAR contained within.

                          • 10. Local EJB binding in AS 6
                            mick_mcgovern1

                            Ok,

                             

                            I've managed to get the app to start - by removing a large number of EJBs (SFSB). However the boot time, even with less EJBs, is still slower than 4.2.3 and from what I observed, suspending the thread whilst booting, is that there seems to be some inefficient list/array handling related to EJB contexts. The rate of deploying EJBs speeds up as the lists got smaller. But the code was instantiating new lists, each containing details of the hundreds of EJBs that make up the app. The array seemed to be the exact size required meaning every time it needed to change a new one was instantiated and the content loaded. This app has hundreds of EJBs. I think the original deployment with all EJBs present was suffering some sort of exponential degradation of list/array processing.

                             

                            The class is a CopyOnWriteArrayList and is called from AbstractKernelController.resolveContexts.

                             

                            I think there is some inefficient code happening in there somewhere.

                            • 11. Local EJB binding in AS 6
                              jaikiran

                              This looks bad and actually reminds me of a fix (in MC?) that was done after AS 5.1.0 was released. How many EJBs do you have? How many @EJB injection or <depends> do you have? Would it be possible for you to share this application, so that we can take a look and fix the issue within JBoss AS?

                              • 12. Local EJB binding in AS 6
                                mick_mcgovern1

                                I could share but it would require you to have Oracle installed, to run schema setup etc.

                                 

                                The app has approx 1100 SFSB  - each also having several (say 5) injected EJBs.

                                 

                                there is also about 200 JPA entities.

                                 

                                If you really want I can upload the ear onto an FTP server, a JMX console ear to do schema and instructions.

                                 

                                The main ear is about 50MB.

                                 

                                I've got the app deploying but it takes about twice as long as 4.2.3 did. I did the exercise of removing beans and then readding and I think the only changes I ended up making was to increase the max memory setting and to compile usig JDK6 (was 5).I'm pretty sure that 5.1.0 had the same "loop/slow boot" issue as 6.0.0.

                                • 13. Re: Local EJB binding in AS 6
                                  mick_mcgovern1

                                  I've now gone to AS7.1.0 and this is no longer an issue