‘System.OutOfMemoryException’ when generating Analysis reports and graphs

If the Analysis takes a very long time to generate graphs and reports for a large results set or ‘System.OutOfMemoryException’ error is seen in the Analysis logs then to improve the Analysis reports and graphs generation enable the 3 GB mode on the Analysis machine

To do this:

For x64 windows – Just have 4 GB or more memory.

For x32 windows – have 4 GB of memory and do the following:

Run -> msconfig

Boot tab

Advanced options… button

Check the Maximum memory and put to the field maximum allowed value ( usually it is 3072 )

Advertisements

After migration from QC 9.2 to ALM 11 problems with the group permissions

After migrating from Quality Center (QC) 9.2 to Application Lifecycle Management (ALM) 11 issues with the Group permissions could cause different problems.

Note: If the above is not the exact reason for using this fix, running this repairer will actually cause a security breach exposing this entity for update. This is a situation that needs to be avoided.

One such example would be that although a user belongs to a group with the permissions to create and update design steps, the user also cannot create a new design step by copy and paste. The ALM current permission model has a rule. If a group has the update permission over at least one of an entity’s fields that is exposed in the permissions User Interface (UI), it should also have the update permission over that entity. Before running this repairer there might be an entity with permissions to update its fields, but without permissions to update the entity itself for some group. In this situation, the entity is blocked in all or most use cases from being updated in the database (DB). After running this repairer this entity will have permissions for updating the entity. This means that in all use cases it will be allowed to update this entity. And also, on the contrary, if an entity has the permission of updating itself without the permission of updating its fields, running the repairer will lead to disabling updating the entity.

It is caused by a change in the way that Group permissions work between QC 9.2 and ALM 11.

The problem could be fixed, by following the below steps:

1. Add the below contents to the following files:

"verify_tasks_deep.xml" and "repair_tasks.xml" under "repository\sa\DomsInfo\MaintenanceData\conf".

For verify_tasks_deep.xml – <ENTRY VALUE="com.mercury.td.saserver.maintenance.verify.EntityUpdatePermissionInconsistencyTask"/>

For repair_tasks.xml – <RepairData class="com.mercury.td.saserver.maintenance.repair.EntityUpdatePermissionInconsistencyRepairer"/>

2. Restart the ALM server.

3. Run the Project Repair Tool.

4. When the migration of the projects is done, remove the lines from the XML files

5. Restart the ALM server

Note: After adding the contents to these files, restarting ALM server, and repairing the project, the greyed out buttons should be enabled.

Note: The above class is disabled (not declared in the list of verifiers/repairers) by default, since it may contain a hidden risk. For example, in the above case, if the "SYSTEM_FIELD.SF_GRANT_MODIFY" is incorrect, the repairer will always align "TABLES.TB_GRANT_MODIFY" to it.

Note: It is very important to remove the lines from the XML files once the repair has finished so other projects are not changed.