> Double invocation shouldn't be the case (and isn't mentioned in the original description of this issue).

It looks that it is easy to miss, tests usually verify that interceptor is invoked at all. Should I file a new issue then, or what is the most appropriate place to discuss this in detail?

> There could be a problem in how Paraya integrates with Weld though, black magic is involved when it comes to CDI and EJB interoperability on EE servers.

Yes, my current task is to fix that black magic, but the problem appears to be on your side of the spell - Payara's EJB container will delegate to Weld-produced instance after it has done all of the interception steps mandated by EJB spec. And this weld subclass applies AroundInvoke interceptors again, even though we're operating in context of EJB message inflow.

> I wonder if you can reproduce this on WFLY, I suppose it won't be happening there.

No problem in WildFly, because it doesn't use the code introduced in WELD-2404 at all – instantiation of the MDB in WF doesn't involve EjbSupportImpl#createMessageDrivenInjectionTarget or BeanManager#createInjectionTarget(EjbDescriptor). So it's a quite different strategy to what is documented as recommended EJB container integration approach.