Tevékenységek

március 25
Graeme Steyn hozzászólást küldött LPS-26665-hez.
3:57 Created a new pull request to Julio Camarero as the originalone was directly to the liferay master. https://github.com/juliocamarero/liferay-portal/pull/1565
Graeme Steyn hozzászólást küldött LPS-33129-hez.
3:04 Created new pull request to Jorge Ferrer for the 6.2.x version of the fix. https://github.com/JorgeFerrer/liferay-portal/pull/147
március 13
Graeme Steyn hozzászólást küldött LPS-33129-hez.
23:29 Related to http://issues.liferay.com/browse/LPS-9376 where auto.deploy.copy.log4j=true was introduced.
február 25
Graeme Steyn hozzászólást küldött LPS-30992-hez.
15:11 Hi Juan, I had a breif response from our systems admininstrator about our LDAP performance and got the following as possible causes for the slow performance of our LDAP system ("The ldap query is taking 11 seconds to run on test, but it takes <1s to run on production"). * "No I haven't had a chance to find out what it is. If I had to guess I'd say the hardware it's running on. The old sun hardware runs low on memory, as the queries that liferay does on the LDAP servers flog the hell out of it and it caches everything. This then causes it to go to swap so things swap out and in as needed." The original investigation that I did resulted in the changes as outlined in LPS-28638, LPS-28639 and LPS-28640. I was still experiencing the following in our test environment. {noformat} I have finished going through the code and introduced 2 optimizations and some fixes for the returning of the connections to the LDAP pool. The LDAP connection pool is now working correctly. However, there are still very long response times involved in the test environment. Here is an extract of some of the logging that I have introduced to get a better idea of where the time is being spent (last figure on logging line is time in ms from some custom timers inserted at specific points). 1543 2012-07-18 03:21:47,005 [INFO ] [tomcat-http--34] [com.liferay.portal.security.auth.OpenSSOAutoLogin:?] 02 Get OpenSSO Attributes in OpenSSOAutoLogin 31 1544 2012-07-18 03:21:47,006 [INFO ] [tomcat-http--34] [com.liferay.portal.security.auth.OpenSSOAutoLogin:?] 03 Check for existing user in OpenSSOAutoLogin 0 1545 2012-07-18 03:21:47,020 [INFO ] [tomcat-http--34] [com.liferay.portal.security.ldap.PortalLDAPImporterImpl:?] 14 Search for User in importLDAPUser 2 1588 2012-07-18 03:21:58,582 [INFO ] [tomcat-http--34] [com.liferay.portal.security.ldap.PortalLDAPImporterImpl:?] 15 Get user attibutes in importLDAPUser 11561 1593 2012-07-18 03:21:58,598 [INFO ] [tomcat-http--34] [com.liferay.portal.security.ldap.PortalLDAPImporterImpl:?] 08 Import User in PortalLDAPImporterImpl 16 1596 2012-07-18 03:21:58,648 [INFO ] [tomcat-http--34] [com.liferay.portal.security.ldap.PortalLDAPImporterImpl:?] (&(&(ou:dn:=groups)(objectClass=groupOfUniqueNames)(uniqueMember=*))(uniqueMember=uid=s0184076,ou=people,dc=cqu,dc=edu,dc=au)) 1653 2012-07-18 03:22:15,748 [INFO ] [tomcat-http--34] [com.liferay.portal.security.ldap.PortalLDAPImporterImpl:?] 11 PortalLDAPUtil.searchLDAP 17100 1660 2012-07-18 03:22:17,225 [INFO ] [tomcat-http--34] [com.liferay.portal.security.ldap.PortalLDAPImporterImpl:?] 12 Add and delete useer from groups 1477 1661 2012-07-18 03:22:17,230 [INFO ] [tomcat-http--34] [com.liferay.portal.security.ldap.PortalLDAPImporterImpl:?] 09 Import Groups in PortalLDAPImporterImpl 18631 1662 2012-07-18 03:22:17,230 [INFO ] [tomcat-http--34] [com.liferay.portal.security.ldap.PortalLDAPImporterImpl:?] 10 importLDAPUser in PortalLDAPImporterImpl 30224 1663 2012-07-18 03:22:17,230 [INFO ] [tomcat-http--34] [com.liferay.portal.security.auth.OpenSSOAutoLogin:?] 04 LDAP user import SN in OpenSSOAutoLogin 30224 1664 2012-07-18 03:22:17,230 [INFO ] [tomcat-http--34] [com.liferay.portal.security.auth.OpenSSOAutoLogin:?] 07 User NULL check in OpenSSOAutoLogin 0 From the section above and from thread dumps that I have being taking there appear to be two hot spots. 1. (&(&(ou:dn:=groups)(objectClass=groupOfUniqueNames)(uniqueMember=*))(uniqueMember=uid=xxxx,ou=people,dc=xxx,dc=xxx,dc=xx)) = 17.1 seconds to return. 2. Another query that gets the LDAP properties for a group using the groups FullDN, e.g. cn=all-students,ou=groups,dc=xxx,dc=xxx,dc=xx. The LDAP properties that it retrieves are: cn, description, creatorsName, createTimestamp, modifiersName, modifyTimestamp - this query often appears to have threads waiting for a lock. 3. Retrieving the user’s attributes is also slow at about 11.561 seconds. This is normally a query using the Full DN for the user and a list of specified attributes values to retrieve, e.g. uid, mail, givenName, sn, title, displayName, isMemberOf, creatorsName, createTimestamp, modifiersName, modifyTimeStamp. I have done as much as I can in the current code. {noformat} Hope some of this helps.
február 20
Graeme Steyn frissítette LPS-33129-t.
3:04 Frissített státusz Contributed Solution-hez<br />
Graeme Steyn hozzászólást küldött LPS-33129-hez.
3:04 Code changes for this enhancement have been included in the two commit requests.
február 14
Graeme Steyn hozzászólást küldött LPS-28640-hez.
16:34 Hi Juan, The short answer is that I do not believe that this will help with bulk imports in the case of LPS-30992. It will however assist a little with LDAP pool connections if user information is pulled in via multiple threads during login. Most of the NamingEnumeration references should have been closed as part of LPS-28638 - LDAP failure to close NamingEnumeration causing thread locks. The additional NamingEnumeration closure line included in this patch forces early closure so that a connection is released back to the LDAP pool early. If you check the code, the &#034;enu&#034; does not need to remain open while the remaining thread activities deal with updating the database, etc. For example, if the database interaction is slow due to locking or some other reason, then the &#034;enu&#034; would have been held onto unnecessarily using the older code. All of this assumes that the LDAP pool has been correctly configured as outlined in LPS-28639 - LDAP Connection Pooling settings error This will generally help with performance where multiple users are login in and their details are being imported on login (e.g. as a result of open.sso.ldap.import.enabled=true), as each login will be using one of the LDAP connections. Bulk imports on start-up, however, will not necessarily benefit as the import does not appear to use multiple threads in this case. If I recall the code correctly, bulk imports appear to be serialised with effectively only one LDAP connection being used. In this case the LDAP server response may be the problem. We have had a situation for a while where our production LDAP system responds well, but for some reason our test environment LDAP servers will take as long as 10 seconds for the same operation. I will have to follow-up with our systems administrator to see if he has got any further resolving this - it may just be a LDAP server configuration item (possible LDAP indexes?). In relation to the PermGen error, you may want to double check that a read timeout has resulted in the correct closure of resources similar to LPS-28638 - LPS-30992 shows that the error is simply caught and logged at Line 700 in PortalLDAPImporterImpl. I have unfortunately, not traced through to check the effects on resources from this point or before this point.
február 12
Graeme Steyn hozzászólást küldött LPS-28640-hez.
3:09 Git pull requests are: https://github.com/liferay/liferay-portal/pull/317 - master (6.2.x) https://github.com/liferay/liferay-portal/pull/316 - 6.1.x branch
Graeme Steyn frissítette LPS-26665-t.
2:57 Frissített státusz Contributed Solution-hez<br />
Graeme Steyn hozzászólást küldött LPS-26665-hez.
2:57 Proposed fixed based on what we are running in 6.1.20 EE in production.
Feliratkozás Graeme Steyn tevékenységeire. (Új ablakot nyit)