-
1. Local EJB binding in AS 6
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
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
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
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
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
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
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
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
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
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
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
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.
-