Timeout exception accessing StatefulSessionBeans

[Adrian Flynn]

Hi all

This is my first post to this forum, so I'll try to be succinct.

I am attempting to migrate my mature application (first built on JBoss 4) from Wildfly 32.0.1 to the latest version (39.0.1), however on each version from 36.0.1 onwards, I am unable to call any method on any stateful session beans, with the following being returned each time:

TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key InfinispanBeanMetaDataKey(UUIDSessionID [e19aee8e-3245-4965-8da4-869805c70eb0]) and requestor GlobalTransaction{id=125, addr=wildfly-vm, remote=false, xid=null, internalId=-1}. Lock is held by GlobalTransaction{id=124, addr=wildfly-vm, remote=false, xid=null, internalId=-1}
at org.infin...@15.1.7.Final//org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.get(DefaultLockManager.java:299)
at org.infin...@15.1.7.Final//org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.get(DefaultLockManager.java:229)
at org.infin...@15.1.7.Final//org.infinispan.util.concurrent.locks.impl.InfinispanLock$LockPlaceHolder.checkState(InfinispanLock.java:554)
at org.infin...@15.1.7.Final//org.infinispan.util.concurrent.locks.impl.InfinispanLock$LockPlaceHolder.lambda$toInvocationStage$3(InfinispanLock.java:484)
at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:646)

"wildfly-vm" is the name of my wildfly node. It is configured for clustering, but is the only node in the cluster. JGroups is configured to use TCP.

If I disable passivation on the SFSB, then it works. If I change the cache-ref to "simple" in  ejb3:session-bean:stateful, then it works, but in production I need these beans to be distributable.

I have tested each Wildfly version in turn and had no difficulty up to 35.0.1, but the above error appears from 36.0.1 onwards.

The only differences in my standalone-full-ha.xml configuration from 35.0.1 and 36.0.1 are:

infinispan version incremented from "14.0" to "15.0"

remoting version incremented from "7.0" to "8.0"

undertow version changed from "14.0" to "community:14.0"

I have rebuilt my application using the appropriate wildfly-ee-with-tools BOM for each version.

The error is triggered by making a call to any method on the Stateful Session Bean after instantiating it using ctx.lookup(jndiName). There is a 15 second delay, then the above exception is thrown.

I just don't know where to start looking next. Any suggestions please?

Many thanks

Adrian

[Adrian Flynn]

So I found the cause of this problem... (recording it here in case anyone else comes looking)

For many years my application has been running happily in a clustered environment with @Local interfaces only, on each of the Stateful Session Beans.

The beans happily passivated and were shared across the nodes in the cluster.

In hindsight it may seem a bit obvious, but Wildfly 36+ does not appear to permit the use of @Local interfaces on SFSBs in a clustered environment, generating the exceptions below.

The solution was simply to change the annotation on my SFSB interfaces from @Local to @Remote and I can now use my SFSBs exactly as before.

Now on to the next problem!

Regards

Adrian

[Paul Ferraro]

Hi Adrian,

Can you provide more context for the exception from your initial post? From where are you creating/invoking your SFSBs?  What does your jndi name look like?

Presumably, this is a local invocation (hence the use of @Local), but either way, there should be no requirement that a clustered environment only use @Remote SFSBs.

Given that SFSB invocations are not concurrent, a lock acquisition issue like this is strange - since Infinispan transaction context is propagated alongside the EJB transaction context.

> "wildfly-vm" is the name of my wildfly node. It is configured for clustering, but is the only node in the cluster. JGroups is configured to use TCP.

Not that this should affect the functionality of your application, but why incur the overhead of a JGroups cluster if you do not need it?  Just curious.

Paul