|
[
Permlink
| « Hide
]
Matt Ryall [Atlassian] added a comment - 10/Sep/07 08:49 PM
Increasing priority. This seems to be a serious problem.
If you need any additional logs on this, just let me know.
is there any ETA on this? this is impacting our live installation
We're investigating this issue, and will update as soon as we have more details or an ETA.
I'm pretty sure that this is the cause of a noticeable slowdown relating to the pagetree and children macros since upgrading from 2.2.10 to 2.5.6 (all users are sourced from LDAP but we have a lot of LDAP and local groups) – it would be wonderful if this could be fixed in the near future!
We're seeing this problem as well. We're running Confluence 2.5.6 with Oracle 10, and doing LDAP authentication from Active Directory. I can consistently reproduce the problem by: 1) Start Confluence.
Dushyanth,
Remove the cache="true" from the <hibernate line of your Atlassian-users.xml to "work around" this bug. Thanks, Charles Kevin Hill Hi Charles,
Thanks, Here's an easier way to replicate the problem:
I'm not sure if the user must be an admin in either or both cases, but in my test (3 times in a row) they were. In another test, logging in as an LDAP user first allowed the instance to run for 30 minutes before crashing. We are experiencing this problem, too. Apparently the cache functionality changed when going to 2.5.6 (
Without caching every operation that involves multiple pages (e.g. pagetree, contentbylabel) takes at worst tens of times longer to process in authenticated sessions. For more details refer to https://support.atlassian.com/browse/CSP-11453 When examinating our log files, I noticed the same error messages as in the description, even though caching is not enabled for hibernate. They occur together with a getUserFromCookie failure tens of times a day and are not visible to the users, as far as I know.
2007-09-19 14:24:02,758 ERROR [http-8080-Processor16] [net.sf.hibernate.LazyInitializationException] <init> Failed to lazily initialize a collection
- no session or session was closed
net.sf.hibernate.LazyInitializationException: Failed to lazily initialize a collection - no session or session was closed
at net.sf.hibernate.collection.PersistentCollection.initialize(PersistentCollection.java:209)
--
2007-09-19 14:24:02,762 WARN [http-8080-Processor16] [atlassian.seraph.auth.DefaultAuthenticator] getUserFromCookie Cookie login failed with exception: net.sf.hibernate.LazyInitializationException: Failed to lazily initialize a collection - no session or session was closed
net.sf.hibernate.LazyInitializationException: Failed to lazily initialize a collection - no session or session was closed
at net.sf.hibernate.collection.PersistentCollection.initialize(PersistentCollection.java:209)
The attached atlassian-user JAR includes a fix for this issue in Confluence 2.5.6 and 2.5.7. To install it, please do the following:
If you still experience the problem after restarting Confluence with this new JAR, please attach a copy of the complete stack trace to this issue. After an hour in our QA environment the perfomace after applying the fix is very promising!
How mature for production should this fix be seen as? Major speed improvement here – previously using children=2 in menus for a space using Builder was unusable (30-40 seconds per page load) – it's now quite snappy.
The fix has been tested thoroughly here, and will be shipped in the next version of Confluence. The updated JAR actually includes two fixes:
However, I'd still recommend evaluating this in your test environment for any situation we may have missed. Particularly with LDAP user management, every configuration is different, and you should perform testing before putting any patch into production. Note: caching is enabled by default in Confluence 2.5.7, if you used a copy of the shipped atlassian-user.xml.
For the previous versions, or if you have customised atlassian-user.xml, please do the following:
<hibernate name="Hibernate Repository" key="hibernateRepository" description="Hibernate Repository" cache="true"/>
Is this issue isolated to 2.5.6 & 2.5.7? Namely, is it something that could effect 2.6.0 released today?
This is fixed in 2.6.0. We're considering a 2.5.8 release so people can get a "stable" release with this fix. I will update the fix versions on this issue as appropriate.
Has any of the customers on this list tried 2.5.8 yet? If so, what is your experience? I'm a little gun shy of upgrading since this bug bit our production deployment really baddly. Any input from customers out there?
Running 2.5.6 here with the jar posted above with zero problems for 3 weeks now.
2.5.7 and 2.5.8 were pretty minor updates (other than this fix) so just didn't have much incentive to upgrade (waiting on a later 2.6 or 2.7 release). No problems here either, running 2.5.7 with the patch.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||