2 Replies Latest reply on Jan 23, 2019 2:38 PM by david01337

    JNDI lookups are failing on remote node in infinispan cluster

    david01337
    david01337 Jan 18, 2019 4:43 PM

      We have a cluster of two nodes using Infinispan 9.3 with WF 14. When a change occurs to a cached value on node 1, node 2 begins executing the entry processor for the given key and that logic requires some JNDI lookups. Regardless of what it is EJBContext, other stuff our application puts there, it's failing when any non-remote call succeeds. We're creating an InitialContext and doing initialContext.lookup and expecting results. Especially for "java:comp/EJBContext", shouldn't this always be there? Beans are executing their work so I'd expect to be able to find the EJBContext via initialContext.lookup, but no.

      • 202 Views
      • Tags:
        • 1. Re: JNDI lookups are failing on remote node in infinispan cluster
          pferraro
          pferraro Jan 23, 2019 11:21 AM (in response to david01337)

          According to §11.15 the EJB specification:

          "The container must make a component’s EJBContext interface available either through injection using the Resource annotation or in JNDI under the name java:comp/EJBContext"

           

          So, no, the EJBContext is not required to be accessible via JNDI.  WildFly makes it available via injection using the Resource annotation.  The issue here is that your Infinispan entry processor is not managed by WildFly, and thus does not have the proper context to resolve an EJBContext, even via the Resource annotation.  Rather, what you'll want to do is create the entry processor using a pre-resolved EJBContext so that you can use it when the entry processor fires.  If you paste the appropriate code, I can hopefully help with the wiring.

          1 of 1 people found this helpful
            • Actions
          • 2. Re: JNDI lookups are failing on remote node in infinispan cluster
            david01337
            david01337 Jan 23, 2019 2:38 PM (in response to pferraro)

            Hi, thank you for taking the time to provide some insight.

            You are probably correct in your identification of the problem, that the EJBContext is not available because the entry processor is not managed by WildFly. Further, I agree that creating the entry processor using a pre-resolved EJBContext would make it usable.

             

            However, the EntryProcessor instantiation in my situation is out of my hands. Infinispan's infrastructure performing the caching is serializing an EntryProcessor instance on one WildFly node (where EJB Context is available and being utilized), then the serialized EntryProcessor is sent (Infinispan, not my code) to another clustered node and Infinispan infrastructure de-serializes and executes the "process" method before any of my code is executed. Since that's the case, I don't really have an opportunity / hook / place to create the entry processor using pre-resolved EJBContext. It's out of my hands in the Infinispan infrastructure.

              • Actions