[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2910) Timing problem during login

Peter Johnson (JIRA) jira-events at lists.jboss.org
Mon Apr 21 10:49:44 EDT 2008


    [ http://jira.jboss.com/jira/browse/JBSEAM-2910?page=comments#action_12409802 ] 
            
Peter Johnson commented on JBSEAM-2910:
---------------------------------------

No I am not in debug mode (I assume you mean starting the JVM with the -Xdebug and related options). I have found that using a debugger to track down thread timing issues is usually counter-productive. Instead, I added logging statements to track this down, but only after I noticed the error without any logging, and then when I added the logging I made sure that the behavior was similar. For example, without my extra logging, 3 of the 4 users get logged in just fine and one gets the error. With the logging code, 2 users get logged in and 2 users get the error. (At one point I added too much logging, got a 1/2GB log file, and all 4 users logged in just fine.)

> Timing problem during login
> ---------------------------
>
>                 Key: JBSEAM-2910
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-2910
>             Project: Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0.1.GA, 2.0.0.GA
>            Reporter: Peter Johnson
>         Attachments: createItem.jmx, createItem_noredirect.jmx, createUsers.jmx
>
>
> There is a timing hole during the first login attempt within an application if two or more users attempt to login at the same time.
> I am scripting the SeamBay app that comes with Seam. My JMeter script signs in a random user, and then registers an item to sell, and then logs back out. Earlier (before adding the extra logging), the problem occurred during registering an item to sell phase of the script. With the extra logging, a problem showed up during used signin. Being a firm believer in tackling the initial problem first, I decided to added yet more logging to track that down.
> At one point I added too much logging, and suddenly signin was working again. This lead me to suspect a timing issue. So I backed off on some of the logging and finally narrowed the problem down. It is a timing issue.
> Assume that two users attempt to sign in at exactly the same time, and this is the first time any user has logged in. Each user's request is handled by a separate jbossas thread. What follows is an excerpt of the code that is processed (I abbreviate org.jboss.seam as simply seam, and all line numbers are from the Seam 2.0.1.GA source):
> # seam.security.Configuration.instance() is called to get the security config instance (line 73)
> # seam.Component.getInstance("org.jboss.seam.security.configuration") calls next getInstance (line 1834)
> # seam.Component.getInstance(...), in line 1839 the call to Contexts.lookupInStatefulContexts(name) returns null because the security config instance has not yet been created, then line 1840 calls the next getInstance(...)
> # seam.Component.getInstance(...), in line 1861, create is true and result is null, so getInstanceFromFactory() is called at line 1863
> # seam.Component.getInstanceFromFactory(..), eventually gets to line 1927, where handleFactoryMethodResult() is called
> Now, the first thread to handleFactoryMethodResult(), when it gets to line 1939, the call to Contexts.lookupInStatefulContexts() returns null because the security config instance is not yet created. Which is fine because the 'create' flag is set to true so the security config gets created (back in getInstance, at line 1873)and placed into the APPLICATION context.
> Then the second thread gets to handleFactoryMethodResult() line 1939, but its call to Contexts.lookupInStatefulContexts() returns the object created by the first thread. This cause the code to branch to the else statement as line 1949, and because the scope is not UNSPECIFIED, the expetion that I was seeing gets thrown.
> The problem is that after the Contexts.lookupInStatefulContexts(name) at line 1839, the APPLICATION context (at least) should be locked until that getInstance method exists, or the code in handleFactoryMethod needs to be a little more understandung if unexpected objects suddenly show up. I image that the former is the correct mechanism.

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

        



More information about the seam-issues mailing list