[JBoss JIRA] Created: (GTNPORTAL-1870) Login time of user "root" depends on number of users in DB
by Marek Posolda (JIRA)
Login time of user "root" depends on number of users in DB
----------------------------------------------------------
Key: GTNPORTAL-1870
URL: https://issues.jboss.org/browse/GTNPORTAL-1870
Project: GateIn Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Identity integration, Performance
Affects Versions: 3.1.0-GA
Environment: EPP 5.1.0.GA
Reporter: Marek Posolda
Assignee: Boleslaw Dawidowicz
Fix For: 3.2.0-GA
When we have 100000 users in DB, then login of user root took me 3 minutes on my laptop. With million users in DB is login of user root impossible . The cause is that method GroupDAOImpl.getAllGroups() is called for user "root" and CPU time of this method depends on number of users in database. This method has 2 possible bottlenecks:
1) Method GroupDAOImpl.getAllGroups() is internally running RelationshipManagerImpl.findAssociatedGroups for root group, which in next turn means recursive call of method RelationshipManagerImpl.findAssociatedGroups for each group in DB. This method is sending SQL, which is looking for all children under specified group. Problem is that these children can be both users or other groups and users are then filtered and removed from final result by algorithm at the end of method RelationshipManagerImpl.findAssociatedGroups().
When having 1000000 users and method RelationshipManagerImpl.findAssociatedGroups() is called for IDM group equivalent to "/platform/users", then we have 1000000 objects in result from Hibernate call. And this is the cause of bottleneck. This SQL is called (4 is ID of group "users" in table "jbid_io") :
select distinct hibernatei1_.ID as ID4_, hibernatei1_.IDENTITY_TYPE as IDENTITY2_4_, hibernatei1_.NAME as NAME4_, hibernatei1_.REALM as REALM4_ from jbid_io_rel hibernatei0_ inner join jbid_io hibernatei1_ on hibernatei0_.TO_IDENTITY=hibernatei1_.ID, jbid_io_rel_type hibernatei3_ where hibernatei0_.REL_TYPE=hibernatei3_.ID and (hibernatei1_.NAME like '%') and hibernatei3_.NAME='JBOSS_IDENTITY_MEMBERSHIP' and hibernatei0_.FROM_IDENTITY=4;
Running of this SQL is expensive and another thing, which I am seeing from profiling, is that big amount of CPU time is also spend by caching of this result in Hibernate Query Cache (which is very bad for memory as well because it needs to cache 1000000 HibernateIdentityObject instances with all users).
2) Second thing in GroupDAOImpl.getAllGroups() is calling of method convertGroup(), which needs to call DB requests to obtain attributes for concrete group. Hibernate is using these selects (for group with ID 1) for obtain attributes:
select attributes0_.IDENTITY_OBJECT_ID as IDENTITY2_4_1_, attributes0_.ATTRIBUTE_ID as ATTRIBUTE1_1_, attributes0_.ATTRIBUTE_ID as ATTRIBUTE1_9_0_, attributes0_.IDENTITY_OBJECT_ID as IDENTITY2_9_0_, attributes0_.NAME as NAME9_0_, attributes0_.ATTRIBUTE_TYPE as ATTRIBUTE4_9_0_, attributes0_.BIN_VALUE_ID as BIN5_9_0_ from jbid_io_attr attributes0_ where attributes0_.IDENTITY_OBJECT_ID in (select hibernatei1_.ID from jbid_io_rel hibernatei0_ inner join jbid_io hibernatei1_ on hibernatei0_.TO_IDENTITY=hibernatei1_.ID, jbid_io_rel_type hibernatei3_ where hibernatei0_.REL_TYPE=hibernatei3_.ID and (hibernatei1_.NAME like '%') and hibernatei3_.NAME='JBOSS_IDENTITY_MEMBERSHIP' and hibernatei0_.FROM_IDENTITY=1);
select textvalues0_.TEXT_ATTR_VALUE_ID as TEXT1_9_0_, textvalues0_.ATTR_VALUE as ATTR2_0_ from jbid_io_attr_text_values textvalues0_ where textvalues0_.TEXT_ATTR_VALUE_ID in (select attributes0_.ATTRIBUTE_ID from jbid_io_attr attributes0_ where attributes0_.IDENTITY_OBJECT_ID in (select hibernatei1_.ID from jbid_io_rel hibernatei0_ inner join jbid_io hibernatei1_ on hibernatei0_.TO_IDENTITY=hibernatei1_.ID, jbid_io_rel_type hibernatei3_ where hibernatei0_.REL_TYPE=hibernatei3_.ID and (hibernatei1_.NAME like '%') and hibernatei3_.NAME='JBOSS_IDENTITY_MEMBERSHIP' and hibernatei0_.FROM_IDENTITY=1));
When profiling, I am seeing that these selects are slow because attributes of groups are in same DB table as attributes of user ( When we have million users and each user has 7 attributes, then we have around 7000000 items in tables "jbid_io_attr" and in table "jbid_io_attr_text_values" )
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (GTNPORTAL-1944) DateTimeValidator has superflous code that breaks localized date timestamps
by Matt Davis (JIRA)
DateTimeValidator has superflous code that breaks localized date timestamps
---------------------------------------------------------------------------
Key: GTNPORTAL-1944
URL: https://issues.jboss.org/browse/GTNPORTAL-1944
Project: GateIn Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: WebUI
Affects Versions: 3.1.0-GA
Reporter: Matt Davis
http://anonsvn.jboss.org/repos/gatein/epp/portal/tags/EPP_5_1_0_GA/webui/...
has an additional check where the date input value needs to match the (not localized) DATETIME_REGEX, which is superfluous and causes localized date input to fail:
Index: core/src/main/java/org/exoplatform/webui/form/validator/DateTimeValidator.java
===================================================================
--- core/src/main/java/org/exoplatform/webui/form/validator/DateTimeValidator.java (revision 6667)
+++ core/src/main/java/org/exoplatform/webui/form/validator/DateTimeValidator.java (working copy)
@@ -43,17 +43,11 @@
public class DateTimeValidator implements Validator
{
- static private final String SPLIT_REGEX = "/|\\s+|:";
-
- static private final String DATETIME_REGEX =
- "^(\\d{1,2}\\/\\d{1,2}\\/\\d{1,4})\\s*(\\s+\\d{1,2}:\\d{1,2}:\\d{1,2})?$";
-
public void validate(UIFormInput uiInput) throws Exception
{
if (uiInput.getValue() == null || ((String)uiInput.getValue()).trim().length() == 0)
return;
String s = (String)uiInput.getValue();
- DateFormat stFormat = new SimpleDateFormat("MM/dd/yyyy HH:mm:ss");
UIFormDateTimeInput uiDateInput = (UIFormDateTimeInput)uiInput;
SimpleDateFormat sdf = new SimpleDateFormat(uiDateInput.getDatePattern_().trim());
@@ -79,24 +73,5 @@
{
throw new MessageException(new ApplicationMessage("DateTimeValidator.msg.Invalid-input", args, ApplicationMessage.WARNING));
}
- if (s.matches(DATETIME_REGEX) && isValidDateTime(s))
- return;
-
- throw new MessageException(new ApplicationMessage("DateTimeValidator.msg.Invalid-input", args, ApplicationMessage.WARNING));
}
-
- private boolean isValidDateTime(String dateTime)
- {
- String[] arr = dateTime.split(SPLIT_REGEX, 7);
- int valid = Integer.parseInt(arr[0]);
- if (valid < 1 || valid > 12)
- return false;
- Calendar date = new GregorianCalendar(Integer.parseInt(arr[2]), valid - 1, 1);
- if (Integer.parseInt(arr[1]) > date.getActualMaximum(Calendar.DAY_OF_MONTH))
- return false;
- if (arr.length > 3
- && (Integer.parseInt(arr[3]) > 23 || Integer.parseInt(arr[4]) > 59 || Integer.parseInt(arr[5]) > 59))
- return false;
- return true;
- }
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (GTNPORTAL-1933) actionScopedRequestAttributes not available for portlets
by m l (JIRA)
actionScopedRequestAttributes not available for portlets
--------------------------------------------------------
Key: GTNPORTAL-1933
URL: https://issues.jboss.org/browse/GTNPORTAL-1933
Project: GateIn Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Common integration
Affects Versions: 3.1.0-GA
Environment: Java6
Reporter: m l
javax.portlet.actionScopedRequestAttributes do not seem to be functioning.
This blog post descibes what it should do:
http://wpcertification.blogspot.com/2011/02/actionscopedrequestattributes...
They make possible to call request.setAttribute() from processAction() to RenderRequest, to be available in the PortletFilter.
There is a workaround by using response.setRenderParameter(), but I have a portlet that is already working in Liferay and I'd like to port it to GateIn by having this feature available.
I have this in my portlet.xml:
<container-runtime-option>
<name>javax.portlet.actionScopedRequestAttributes</name>
<value>true</value>
</container-runtime-option>
Still those attributes I set in processAction get lost, and are not available by RenderRequest.getAttribute()
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months