Hi Alex
Just thought I should confirm that I replied to this issue as follows in the
uportal-user forum...
Hi Chris/Alex
We also experienced the bug in 2.6.1 you have alluded to. ie:
Cris J Holdorph wrote:
Another thing that skews these
numbers is that I can only get valid results using users that have
successfully logged in before. Anything above 2 threads with users that
have not previously logged in results in channels failing to render
(with the message "You are not authorized to view this channel").
Extract from our load test report:
===
Concurrency Issue Can Lead to Non-Creation of User Account
It seems like the following error will result in the effective non-creation
of the user account. ie No group membership (UP_GROUP_MEMBERSHIP record) is
created and therefore user can log in, but cannot see any content.
ERROR [http-443-Processor69] portal.RDBMUserIdentityStore.[] Jan/09 14:48:08
- Unable to create lockable group for group/member: EntityGroupImpl
(local.4) Developers/EntityImpl (org.jasig.portal.security.IPerson) user638
org.jasig.portal.groups.GroupsException: Problem getting lock for group 4
To test this hypothesis, the following SQL was run and user638 was listed
(ie no group membership).
SELECT * FROM UP_USER LEFT OUTER JOIN UP_GROUP_MEMBERSHIP ON
up_user.user_name = up_group_membership.member_key
WHERE up_group_membership.member_key IS NULL;
One suggested workaround, if this causes a problem in a live environment, is
to gradually create accounts – eg using a controlled JMeter script.
Another possible workaround (although, as yet, untested by University of
Dundee) is to remove the template user from any groups, as per
http://article.gmane.org/gmane.comp.java.jasig.uportal/7069.
===
At the very least, all DB writes for an account creation should be in a
transaction. But even with a transaction, unless you implement a retry, you
will probably still experience this issue in your tests.
To workaround this for your load tests, I would suggest running an "account
creation" script first - which just gets the login page and performs a
login. Do this for the required accounts, but define a long ramp-up period
to ensure there is not a high-level of concurrency. (Or you could re-design
your main test script to use a long ramp-up period.)
Also, if you have not already done so, you should first remove the UP_USER
records for the problematic accounts.
Hope this helps.
Cheers
Tony
--
View this message in context:
http://jasig.275507.n4.nabble.com/Fwd-uPortal-Peformance-tp2246873p2272661.html
Sent from the uPortal Developers mailing list archive at Nabble.com.
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
