0 Replies Latest reply on May 19, 2015 4:58 PM by Scott Dunbar

    Virtual hosting and CDI / JNDI problems

    Scott Dunbar Newbie

      Hello all,

      I'm trying to use a single instance of WildFly 8.2.0.Final to run our development and staging environments.  I have many @Stateless beans that are injected in various places.  I notice on startup that I get, for example:

       

      2015-05-19 14:12:11,185 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-3) JNDI bindings for session bean named SomeBean in deployment unit deployment "daapp.war" are as follows:

       

              java:global/daapp/SomeBean!com.company.SomeBean

              java:app/daapp/SomeBean!com.company.SomeBean

              java:module/SomeBean!com.company.SomeBean

              java:global/daapp/SomeBean

              java:app/daapp/SomeBean

              java:module/SomeBean

       

      I'll admit I'm still learning so bear with me but if I understand JNDI names are "global" in nature.  So if I try to deploy the same war file twice I feel like I'll get naming collisions.

       

      The virtual host deployments are supposed to be totally separate.  I've handled different JMS topic names (something I also believe to be "global") via ejb-jar.xml that is different between the environments.  Any suggestions on the way to handle this?  I'm getting timeouts on beans with an @Schedule annotation and I believe it to be the same issue:

       

      2015-05-19 14:24:27,006 ERROR [org.jboss.as.ejb3] (EJB default - 5) JBAS014120: Error invoking timeout for timer: [id=94eef421-d244-4681-9cc3-3fd00ec0b15a timedObjectId=daapp.daapp.SomeMaintenanceJob auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@1225be24 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Tue May 19 14:25:22 MDT 2015 timerState=IN_TIMEOUT info=null: javax.ejb.ConcurrentAccessTimeoutException: JBAS014373: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on org.jboss.invocation.InterceptorContext$Invocation@159434d7 - could not obtain lock within 5000MILLISECONDS


      I run in standalone-full configuration.  Would it be better to muck with ports and have multiple Wildfly processes running?

       

      Thanks for any help.