[jboss-jira] [JBoss JIRA] (WFLY-5537) Singleton EJBs with multiple views does not honor Lock semantics

[dhinckle (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571403#comment-13571403 ] 

dhinckle commented on WFLY-5537:
--------------------------------

I am still seeing a problem related to this fix. I have installed WF 12.0.0.Final but I noticed the file dates are slightly earlier than Jason Greene's comment on 1/Mar/18 1:16 AM. I do not know if the [ 12336563 ] is a build even newer than the released version. Below is an explanation of my problem:

I get the following log on WF 12.0.0.Final:
2018-05-04 11:45:55,948 ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component OfflineBalanceSingleton for method public abstract boolean com.xxx.expand.persistence.OfflineBalanceLocal.isValid() throws com.xxx.expand.dataProcessing.reporting.SwitchException: javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0241: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on OfflineBalanceSingleton - could not obtain lock within 5000MILLISECONDS

This is my Singleton and notice that it is also a Timer:
...
@DependsOn({AlarmUtilLocal.SINGLETON_NAME, DataDictionarySingletonLocal.SINGLETON_NAME, ExpandLoggerLocal.SINGLETON_NAME, ServerLocal.SINGLETON_NAME})
@Singleton(name = OfflineBalanceLocal.SINGLETON_NAME)
@Startup
@TransactionManagement(TransactionManagementType.BEAN)
public class OfflineBalance2 extends TimerServiceBase implements OfflineBalanceLocal, TimedObject, TimerServiceLocal {
...
	@Lock(LockType.READ)
	@Override
	public boolean isValid() throws SwitchException {
		return isWithinValidTime(creationTime.get());
	}

Notice that the log error says it couldn't obtain a lock on isValid but it is marked as READ. This does not happen often in the logs, but to my understanding it should never happen.


> Singleton EJBs with multiple views does not honor Lock semantics
> ----------------------------------------------------------------
>
>                 Key: WFLY-5537
>                 URL: https://issues.jboss.org/browse/WFLY-5537
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.CR2
>         Environment: 10.0.0.CR2
>            Reporter: Nicky Mølholm
>            Assignee: Stuart Douglas
>              Labels: ejb, interceptor, singleton
>             Fix For: 12.0.0.Beta1, 12.0.0.Final
>
>
> Upon method invocations to Singleton EJBs with multiple views... the *ContainerManagedConcurrencyInterceptor* randomly selects a wrong Lock (READ / WRITE).
> Here is an example:
> {code:java}
> @Singleton
> @Lock(LockType.READ)
> @Local({ GreeterSayMyName.class, GreeterSayHello.class })
> public class GreeterBean implements GreeterSayMyName, GreeterSayHello {
>     @EJB
>     GreeterSayMyName myself;
>     @Override
>     public String sayHello() {
>         return "hello from " + myself.sayMyName();
>     }
>     @Override
>     public String sayMyName() {
>         return "The Greeter";
>     }
> }
> public interface GreeterSayHello {
>     
>     String sayHello();
>     
> }
> public interface GreeterSayMyName {
>     String sayMyName();
> }
> {code}
> Sometimes (randomly) invoking the 'sayHello' method on this example EJB causes lock upgrade exceptions. They look like this:
> {noformat}
> 13:14:10,436 ERROR [f2PtkwmdRgaoHCdnZ7Vurg] [anonymous] [org.jboss.as.ejb3.invocation] (default task-5 f2PtkwmdRgaoHCdnZ7Vurg) WFLYEJB0034: EJB Invocation failed on component GreeterBean for method public abstract java.lang.String hello.world.GreeterSayHello.sayHello(): javax.ejb.IllegalLoopbackException: WFLYEJB0238: EJB 3.1 PFD2 4.8.5.1.1 upgrading from read to write lock is not allowed
> 	at org.jboss.as.ejb3.concurrency.EJBReadWriteLock.checkLoopback(EJBReadWriteLock.java:232)
> 	at org.jboss.as.ejb3.concurrency.EJBReadWriteLock.access$300(EJBReadWriteLock.java:40)
> {noformat}
> This happens completely randomly. 
> The problem is that the interceptor only knows about one of the views' methods. At deployment time the ViewService will start the views concurrently - and the interceptorfactory only adds an interceptor instance to the interceptor context if one does not already exist. 
> When the exception does NOT occur -then there is still a problem (although not visible from the code): A WRITE lock is selected - even though , given the above code, it should never ever be possible.  So in fact - the issue , in that case, does not cause an exception because .... it already has the WRITE lock. 
> ( When the exception occurs ...then it is because the sayHello() invocation resulted in a READ lock ... and the reentrant invocation caused a WRITE lock to be selected by the interceptor ... but as this is not allowed, it results in a horrible exception )



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)