]
Peter Johnson commented on JBSEAM-2910:
---------------------------------------
One more thing. After running createUsers.jmx, restart the app server before running
createItem_noredirect.jmx. This means you have to make sure that the database is not
recreated on a restart. IMPORTANT: You must ensure that noone has logged into SeamBay
before running the createItem_noredirect.jmx script!
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: