[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-3294) Exception Handling not working under certain conditions

[Maximiliano Carrizo (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBSEAM-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12426123#action_12426123 ] 

Maximiliano Carrizo commented on JBSEAM-3294:
---------------------------------------------

Pete:

     I found the problem. I will detail it with Seam 2.0.3. Version:

1) In Manager class Seam has the following code:

 private boolean restoreAndLockConversation(ConversationEntry ce)
   {
      if ( ce!=null && ce.lock() )
      {
         // do this ASAP, since there is a window where conversationTimeout() might  
         // try to destroy the conversation, even if he cannot obtain the lock!
         touchConversationStack( ce.getConversationIdStack() );

         //we found an id and obtained the lock, so restore the long-running conversation
         log.debug("Restoring conversation with id: " + ce.getId());
         setLongRunningConversation(true);
         setCurrentConversationId( ce.getId() );
         setCurrentConversationIdStack( ce.getConversationIdStack() );

         boolean removeAfterRedirect = ce.isRemoveAfterRedirect() && !Pages.isDebugPage(); //TODO: hard dependency to JSF!!
         if (removeAfterRedirect)
         {
            setLongRunningConversation(false);
            ce.setRemoveAfterRedirect(false);
         }
         
         return true;

      }
      else
      {
         //there was no id in either place, so there is no
         //long-running conversation to restore
         log.debug("No stored conversation, or concurrent call to the stored conversation");
         initializeTemporaryConversation();
         return false;
      }
   }

as you can see, method restoreAndLockConversation tries to lock conversation in order to remove it.

2) Class ConversationEntry has lock method, which is invoked in previous method:

   public boolean lock() //not synchronized!
   {
      try
      {
         return lock.tryLock( Manager.instance().getConcurrentRequestTimeout(), TimeUnit.MILLISECONDS );
      }
      catch (InterruptedException ie)
      {
         throw new RuntimeException(ie);
      }
   }

3) Lock variable has ReentrantLock type. This class has the method:

        final int getHoldCount() {
            int c = getState();
            Thread o = owner;
            return (o == Thread.currentThread())? c : 0;
        }


which is used to get hold count. 

The problem is: Sometimes, when App throws an exception ( SOMETIMES ), current thread is different from lock owner thread ( I'd verified it !! ). Because is different, getHoldCount returns 0, Seam thinks that there is no lock of current conversation, enters in the second condition of restoreAndLockConversation and leaves conversation pending.

Of course, I have no idea to solve it... but this is the problem.

       Best regards





> Exception Handling not working under certain conditions
> -------------------------------------------------------
>
>                 Key: JBSEAM-3294
>                 URL: https://jira.jboss.org/jira/browse/JBSEAM-3294
>             Project: Seam
>          Issue Type: Bug
>    Affects Versions: 2.0.3.CR1
>         Environment: Kubuntu, Tomcat 6.0.14, Eclipse Europa 3.3.2 
>            Reporter: Maximiliano Carrizo
>            Priority: Minor
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> I have the following action method:
> 	public String confirm() {
> 		log.info("---------> Saving Selected Role");
> 		securityServices.confirmRole(roleOperationType, selectedRole);
> 		events.raiseTransactionSuccessEvent(Constant.REFRESH_ROLE_LIST);
> 		return Constant.SUCCESS;
> 	}
> This pages config ( exception trapping only ):
> 	<!-- Exceptions Trapping -->
> 	<exception class="javax.persistence.OptimisticLockException">
> 		<end-conversation />
> 		<redirect view-id="/pages/publicArea/errors/genericError.xhtml">
> 			<message>#{messages['dirty_data_error']}</message>
> 		</redirect>
> 	</exception>
> 	<exception class="org.jboss.seam.security.AuthorizationException">
> 		<end-conversation />
> 		<redirect view-id="/pages/publicArea/errors/genericError.xhtml">
> 			<message>#{messages['no_permission_granted']}</message>
> 		</redirect>
> 	</exception>
> 	
> 	<exception class="org.hibernate.StaleObjectStateException">
> 		<end-conversation />
> 		<redirect view-id="/pages/publicArea/errors/genericError.xhtml">
> 			<message>#{messages['record_locked']}</message>
> 		</redirect>
> 	</exception>
> 	<exception class="java.lang.Throwable">
> 		<end-conversation />
> 		<redirect view-id="/pages/publicArea/errors/genericError.xhtml">
> 			<message>#{messages['unknown_error']} #{org.jboss.seam.handledException.getMessage()}</message>
> 		</redirect>
> 	</exception>
> Im testing exception handling functionality of my app. When the service of my action:
> securityServices.confirmRole(roleOperationType, selectedRole);
> throws this exception:
> javax.faces.el.EvaluationException: javax.persistence.PersistenceException: org.hibernate.PropertyValueException: not-null property references a null or transient value: com.teracode.seamapp.security.model.Role.home
> 	at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:91)
> In some cases app works fine ( closes current long-running conversation, opens error page and shows error message ) and in other cases leaves conversation open and dont show error message. I do always the same testing steps over and over .... and sometimes fails and sometimes not. I couldnt find an error criteria, but, when I change parameter concurrent-request-timeout on components.xml, setting a big value, something funny happens. 
> Imagine I set concurrent-request-timeout on ten seconds. If I execute action and app answers me instantly, app works fine. If action lasts for ten seconds, app fails. 
> I thought on sending you an example, but I've tested app at my partners machines, and ...... had the same behavior.
> Best regards

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira