Announcement Announcement Module
Collapse
No announcement yet.
Locking / Unlocking issue with Firefox Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Locking / Unlocking issue with Firefox

    I have an issue with a simple webflow that only occurs when using Firefox.

    I'm using WebFlow 1.0.3 combined with JSF 1.1 / Facelets 1.1.11 on Bea Weblogic 8.1

    I noticed that when using Firefox, upon launching a new flow, or transitioning to a new state in a running flow, I sometimes loose all state information when my page is rendered. Clicking refresh on the browser restores the state and my page renders correctly. This happens on occasion (every couple of requests).

    I don't have this issue when working with IE.

    The only thing I noticed in the logfiles was the following :

    In IE , I see that the locking / unlocking always happens in the same sequence. meaning that a "Locking conversation ..." message is always followed by an "Unlocking conversation..." message before the conversation is locked again.

    Code:
    [org.springframework.webflow.conversation.impl.SessionBindingConversationManager] - <Getting conversation F2314463-5E0A-F8D5-92B4-4D062CD4D051>
    [org.springframework.webflow.conversation.impl.SessionBindingConversationManager] - <Locking conversation F2314463-5E0A-F8D5-92B4-4D062CD4D051>
    [org.springframework.webflow.conversation.impl.SessionBindingConversationManager] - <Putting conversation attribute 'scope' with value map[......
    ......
    [org.springframework.webflow.conversation.impl.SessionBindingConversationManager] - <Unlocking conversation F2314463-5E0A-F8D5-92B4-4D062CD4D051>
    ......
    [org.springframework.webflow.conversation.impl.SessionBindingConversationManager] - <Getting conversation F2314463-5E0A-F8D5-92B4-4D062CD4D051>
    [org.springframework.webflow.conversation.impl.SessionBindingConversationManager] - <Locking conversation F2314463-5E0A-F8D5-92B4-4D062CD4D051>
    [org.springframework.webflow.conversation.impl.SessionBindingConversationManager] - <Putting conversation attribute 'scope' with value map[......
    .....
    [org.springframework.webflow.conversation.impl.SessionBindingConversationManager] - <Unlocking conversation F2314463-5E0A-F8D5-92B4-4D062CD4D051>
    However, when exeuting the exact same flow in FireFox, I sometimes have the following behaviour (this happens when I loose all state information).:

    Code:
    [org.springframework.webflow.conversation.impl.SessionBindingConversationManager] - <Getting conversation 06534B1C-829A-27FE-6A2F-6477DE02AF32>
    [org.springframework.webflow.conversation.impl.SessionBindingConversationManager] - <Locking conversation 06534B1C-829A-27FE-6A2F-6477DE02AF32>
    .....
    [org.springframework.webflow.conversation.impl.SessionBindingConversationManager] - <Getting conversation 06534B1C-829A-27FE-6A2F-6477DE02AF32>
    [org.springframework.webflow.conversation.impl.SessionBindingConversationManager] - <Locking conversation 06534B1C-829A-27FE-6A2F-6477DE02AF32>
    Notice how here, I have 2 "Locking conversation ...." messages, without an "Unlocking conversation ..." message between them. Is this normal ?
    When this occurs, I loose all state, refreshing the page via the browser resolves the issues.

  • #2
    Every 'Lock' should have a matching 'Unlock'.

    Could it be that FireFox somehow thinks that it should display a cached page while IE always (correctly) goes back to the server to reload the page?

    We're investigating this since other people have also reported some Lock/Unlock related issues with the JSF integration (look at the other recent threads on the forum).

    Erwin

    Comment


    • #3
      I have been unable to reproduce this in firefox with the sellitem-jsf sample. Do you see the same problem in this sample application running in your environment? If not, would it be possible for you to submit a minimal version of your flow that consistently exhibits this problem so we can reproduce it?

      What JSF vendor implementation version are you using?

      Keith

      Comment


      • #4
        The problem was related to the fact that the flow was being executed on JDK 1.4 (Bea Weblogic 8.1)

        Deploying the swf-sellitem-jsf app on Tomcat (JDK 1.5) worked fine, while it was causing all sorts of problems on Bea Weblogic (JDK 1.4)

        I've compiled and added Doug Lea's util.concurrent package to the webapp and it appears to be running without any problems now.

        Unfortunately, I missed the warning on the console

        However, I am curious as to why the problem only occured on Firefox. I wasn't able to reproduce the issue on IE.

        Comment


        • #5
          So to confirm: you only had issues on JDK 1.4 BEFORE you plugged in util.concurrent. After plugging in util.concurrent, it worked for you on JDK 1.4 properly. Lastly, your issue was Firefox only.

          Correct?

          That's interesting, as Web Flow uses a "no-op" conversation lock in the case of no java 5 availability and no util.concurrent availability. In this case, things should continue to work - you just won't have synchronized access to the user conversation and flow execution associated with it.

          As a sanity test, can you try removing util.concurrent once more in your working JDK 1.4 environment and see if the problem re-appears? I'm puzzled as to why that would be the cause as much as you.

          Keith

          Comment


          • #6
            The problem seems to occur in the FlowExecutionContinuationGroup :

            Code:
            	public FlowExecutionContinuation get(Serializable id) throws ContinuationNotFoundException {
            		FlowExecutionContinuation continuation = (FlowExecutionContinuation)continuations.get(id);
            		if (continuation == null) {
            			throw new ContinuationNotFoundException(id);
            		}
            		return continuation;
            	}
            If I put a conditional breakpoint (continuation==null) on the if statement, I can see that in fact continuation sometimes resolves to null.
            However if I then inspect the continuations.get(id) (while the thread is suspended) , it returns a valid continuation. So this seems to be some kind of race condition.

            The weird thing is that I only have this on Bea Weblogic 8.1.5 using JDK 1.4 using Firefox.

            I've deployed the flow on Tomcat 4.1.36 (using the same JDK as the one Weblogic is using) without the problem occuring.

            Comment


            • #7
              This is really bizar...
              So we've got code that behaves crazy when using WL 8.1 with FireFox?!?!?

              Would it be possible for you to put a network sniffer between your browser and the server? That way we could see if IE and FireFox communicate differently with the application and possibly get some insight into what is going wrong.

              Erwin
              Last edited by klr8; May 2nd, 2007, 02:04 AM.

              Comment


              • #8
                As an aside, this thread has a guy posting that he has been using SWF on JDK 1.4 / WL 8.1 without problems:

                http://forum.springframework.org/showthread.php?t=38145

                Erwin

                Comment


                • #9
                  What I've noticed on my environment is the following

                  Firefox :

                  In the FlowPhaseListener, BEFORE RENDER RESPONSE, sendredirect is called. When the sendredirect is called on the servletresponse, a new thread is spawned immediately where the same FlowPhaseListener instance is kicked in BEFORE RESTORE VIEW. (this is where SWF will attempt to restore a flow execution).
                  At the same time, the original thread continues AFTER RENDER RESPONSE. (this is where SWF will save the flow execution).

                  So effectively, calling

                  Code:
                  context.getFacesContext().getExternalContext().redirect(url);
                  causes a new thread to be spawn with new FlowPhaseListener processing.

                  IE :

                  In the FlowPhaseListener, BEFORE RENDER RESPONSE, sendredirect is called.
                  When the sendredirect is called, no new thread is spawned.
                  Processing continues till the flowphaselistener has done its job. The FlowPhaseListener AFTER RENDER RESPONSE is called to save the flow execution.
                  Then, the same thread is re-used by the appserver to continue processing. The FlowPhaseListener BEFORE RESTORE VIEW is called to restore the flow execution.


                  This results in the following simultanious threads being executed when using firefox :

                  Code:
                  Thread [ExecuteThread: '11' for queue: 'weblogic.kernel.Default'] (Suspended (access of field continuations in FlowExecutionContinuationGroup))	
                  	FlowExecutionContinuationGroup.add(Serializable, FlowExecutionContinuation) line: 88	
                  	ContinuationFlowExecutionRepository.putFlowExecution(FlowExecutionKey, FlowExecution) line: 182	
                  	FlowPhaseListener.saveFlowExecution(JsfExternalContext, FlowExecutionHolder) line: 395	
                  	FlowPhaseListener.afterPhase(PhaseEvent) line: 244	
                  	PhaseListenerManager.informPhaseListenersAfter(PhaseId) line: 92	
                  	LifecycleImpl.render(FacesContext) line: 134	
                  	FacesServlet.service(ServletRequest, ServletResponse) line: 140	
                  	ServletStubImpl$ServletInvocationAction.run() line: 1072	
                  	ServletStubImpl.invokeServlet(ServletRequest, ServletResponse, FilterChainImpl) line: 465	
                  	ServletStubImpl.invokeServlet(ServletRequest, ServletResponse) line: 348	
                  	WebAppServletContext$ServletInvocationAction.run() line: 6981	
                  	AuthenticatedSubject.doAs(AbstractSubject, PrivilegedAction) line: 321	
                  	SecurityManager.runAs(AuthenticatedSubject, AuthenticatedSubject, PrivilegedAction) line: 121	
                  	WebAppServletContext.invokeServlet(ServletRequestImpl, ServletResponseImpl) line: 3892	
                  	ServletRequestImpl.execute(ExecuteThread) line: 2766	
                  	ExecuteThread.execute(ExecuteRequest) line: 224	
                  	ExecuteThread.run() line: 183

                  Code:
                  Thread [ExecuteThread: '14' for queue: 'weblogic.kernel.Default'] (Suspended (breakpoint at line 76 in FlowExecutionContinuationGroup))	
                  	FlowExecutionContinuationGroup.get(Serializable) line: 76	
                  	ContinuationFlowExecutionRepository.getContinuation(FlowExecutionKey) line: 223	
                  	ContinuationFlowExecutionRepository.getFlowExecution(FlowExecutionKey) line: 162	
                  	FlowPhaseListener.restoreFlowExecution(FacesContext) line: 270	
                  	FlowPhaseListener.beforePhase(PhaseEvent) line: 227	
                  	PhaseListenerManager.informPhaseListenersBefore(PhaseId) line: 73	
                  	LifecycleImpl.executePhase(FacesContext, PhaseExecutor, PhaseListenerManager) line: 85	
                  	LifecycleImpl.execute(FacesContext) line: 70	
                  	FacesServlet.service(ServletRequest, ServletResponse) line: 139	
                  	ServletStubImpl$ServletInvocationAction.run() line: 1072	
                  	ServletStubImpl.invokeServlet(ServletRequest, ServletResponse, FilterChainImpl) line: 465	
                  	ServletStubImpl.invokeServlet(ServletRequest, ServletResponse) line: 348	
                  	WebAppServletContext$ServletInvocationAction.run() line: 6981	
                  	AuthenticatedSubject.doAs(AbstractSubject, PrivilegedAction) line: 321	
                  	SecurityManager.runAs(AuthenticatedSubject, AuthenticatedSubject, PrivilegedAction) line: 121	
                  	WebAppServletContext.invokeServlet(ServletRequestImpl, ServletResponseImpl) line: 3892	
                  	ServletRequestImpl.execute(ExecuteThread) line: 2766	
                  	ExecuteThread.execute(ExecuteRequest) line: 224	
                  	ExecuteThread.run() line: 183
                  In the example above, if thread 14 is executed before thread 11, no continuationId will be found, and the flow will fail. If thread 11 is executed before thread 14, no error occurs.

                  Can this shed some new light on the issue ? I'll try and provide you with some HTTP-level information tomorrow.

                  Comment


                  • #10
                    Mmm.
                    And do you have any idea why WL 8.1 would use a seperate thread with FireFox and not with IE?

                    Erwin

                    Comment


                    • #11
                      Http Analyzer shows the following when clicking on a link to start a flow (http://localhost:8500/Lock/app.jsf?_...ate-individual) :
                      I only recorded the first request, as things start to go wrong there (2 threads spawned when using Firefox).


                      Firefox :

                      Code:
                      GET /Lock/app.jsf;jsessionid=G6lQTqVJnX20k7hkdLCS3R78GTh9Qbr8z7b3bkLynrLLJKCtnB02!1997995148?_flowExecutionKey=_c94FD9D30-26A2-E06C-CF3C-90BE5F8E7335_k6F1D16D9-951B-5756-520B-E0AB105B7714 HTTP/1.1
                      Host: localhost:8500
                      User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
                      Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
                      Accept-Language: en-us,nl-be;q=0.5
                      Accept-Encoding: gzip,deflate
                      Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
                      Keep-Alive: 300
                      Connection: keep-alive
                      Referer: http://localhost:8500/Lock/
                      IE

                      Code:
                      GET /Lock/app.jsf?_flowExecutionKey=_c008D2299-3A04-4DD0-0553-F61D9F8BBDAE_k22D12B1B-770F-9FB0-1245-73262D2B00D2 HTTP/1.1
                      Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
                      Referer: http://localhost:8500/Lock/
                      Accept-Language: nl-be,en-us;q=0.7,fr-be;q=0.3
                      Accept-Encoding: gzip, deflate
                      User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
                      Host: localhost:8500
                      Connection: Keep-Alive
                      Cookie: JSESSIONID=G6gH5zzvcb9jfrQcxK59SDcQCFhHwVr3p3kPLx0Nzn8vvYxVfCGV!1997995148

                      Firefox doesn't send a cookie with the request, IE does
                      Firefox adds Keep-Alive: 300, IE doesn't

                      On Tomcat, Firefox does send a cookie with the request

                      I added a watchpoint on continuations in FlowExecutionContinuationGroup to show the 2 active threads in my debugger.

                      I did have a question about the processing order , why does the redirection occur (BEFORE RENDER RESPONSE) before saving the flow execution (AFTER RENDER RESPONSE).

                      I find this particular problem just as whacky as you do, but I was just wondering why the redirect is called before saving the flowexecution.

                      Comment

                      Working...
                      X