[danielcorrea]

Hi everyone,

I'm having trouble with the app_history table, and I'm not sure why this is happening. The problem occurs in 2 different scenarios:

The first one is when I try to edit a dynaform. Once I click the "edit" link, the application starts to read the app_history like there's no tomorrow, and I have to wait for 2 to 3 minutes before the dynaform edit page opens. You can see this in the attached image "History_table.png".

The second scenario is when I try to export the process. This case is worse, because it takes so long for the application to generate the process "package", that it times-out, making it impossible for me to export most of my processes.

I don't even know why this table is being read. It makes no sense to me that the history table should be queried when opening a dynaform of exporting a process definition, but (hopefully) there may be a reason.

Has anyone ever had this kind of problem? Is there a solution?


Best regards,
Daniel

[amosbatto]

I have never seen these problems before. Is this a new installation? Was it upgraded?

What version of PM are you using? What operating system? What installation method (old automatic installer in PM 3.0.1.7 or earlier, Bitnami installer, or manual installation with tar.gz file)? If you did a manual installation, what versions of PHP, Apache and MySQL do you have?

[danielcorrea]

Hi! It's not a new installation. I think it was upgraded from 2.8 a few months ago, but I'm not sure (I wasn't around then). The OS is Windows and the installation was made using the Bitnami installer (3.0.1.7).

The client has a production and a test environment. The problem did not occur in the test environment, until we've backed up the database from the production environment and restored it in the test environment. The app_history table (app_history.ibd file) has 16 gb, and all other tables have less then 200 mb. Is this normal???

[amosbatto]

16 GB for the APP_HISTORY table is not normal. I don't recommend using the Bitnami installer for a production server. I have seen to many problems with Bitnami installations and we don't have a way to upgrade Bitnami installations to later versions. My recommendation is to install 3.0.1.7 on another server doing a manual install with the tar.gz file. Then, export your workspace from the Bitnami installation to the manual installation.

[StephanS]

Hi there,
I have observed a similar problem since using version 3.x of ProcessMaker for exporting a process.

I `ve recreated this problem, by designing a big process-map (wihtout trigger, mail-templates or dynaforms - just placed the bpmn-objects like pools, lanes, tasks, gateways and artefacts).The objects were repositioned very often on that process-map in order to arrange them.

First, exporting seemed to be broken. Finally I`ve only archived the export by changing the session-timeouts (apache), any limitations in php.ini and waited a long time observing the threads of my linux server (seeing, that the webserver was all time busy with 20% cpu - this was an inidication, that the export was running). It also took several minutes and the exported file was amount 11 MB !!!
I think, the problem is caused by the export process, which exports unnescessary information, maybe the reposition-history.

The re-import of that process worked fine. After re-importing the process I `ve tried to export this copy of the process and there was no problem.
Also, the size of the export of that copy is 670kByte ...

Wow 11MB <--> 670KByte for the same process.

Last tried on my Test-System:
Debian (Linux) 8
Processmaker 3.0.1.8-community
MySQl 5.6.34
PHP 5.6.29
Apache 2.4.10

Maybe, you can reproduce that on PM 3.1.3 ?
Compare exported process-files to a re-imported one...

[amosbatto]

Stephan, Please file a bug report about this at http://bugs.processmaker.com and post the link to the bug report here.

[StephanS]

Hi,
I made a small test with PM 3.1.3 and it seems to be ok. After

export (file1) --> re-import (file1) --> export (file2)

both export-files have the same size (although they are different).
I will do a clean installation (not upgrading PM) of the production environment with pm 3.1.3 next days.
If I will recognize the effect again next time, I will post a bug.

If you are interested in analyzing the 11MB <--> 670 Kbyte difference, I can send these files to you (... I`m not happy with releasing the process to public via uploading them to the bug-tracker... )

[amosbatto]

Stephan, Please email me the files at amos AT processmaker DOT com and I will file a private bug report that isn't publicly accessible. Do you have any additional information to add to the bug report?

[StephanS]

Hi Amos,

thank you very much for this offer. I`ve send you an email with both exports to compare attached.

Please let me know if there is any result.

Thanks,
Stephan

[sgkalluri]

Hello there,

I seem to face this problem with earlier versions of PM. I started using PM 3.0.1.7 at first. Dynaform load and save would take an age.

The issue seems to have disappeared with my current PM 3.1.3. This is the normal installation - not Bitnami.

However, I have a different question now... If one takes a dump of the wf_workflow tables, then one notices that the App_History table occupies 99% of the total dump size. The size of the App_History table goes into GBs, whereas the rest of the tables occupy only a few MBs.

Is it possible to purge part of the App_History table without causing issues to PM operation? That way, one can limit the total database size.

Best wishes,
SGK

[amosbatto]

Is it possible to purge part of the App_History table without causing issues to PM operation? That way, one can limit the total database size.

If you delete the contents of APP_HISTORY, then you won't be able to see the history for the case when you go to Information > Case History, but if that isn't important to you, then you can use this SQL to delete the case history for all cases which have 'COMPLETED' status:

Code: Select all

DELETE FROM AH USING APP_HISTORY AS AH, APPLICATION AS A 
WHERE A.APP_STATUS='COMPLETED' AND A.APP_UID=AH.APP_UID;

You can login to MySQL and execute it like this from the command line:

Code: Select all

$ mysql -u root -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 5530
Server version: 5.5.47-0+deb8u1 (Debian)

Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| PROCESSMAKERTESTDC |
| clients            |
| mysql              |
| performance_schema |
| phpmyadmin         |
| wf_workflow280     |
| wf_workflow3017    |
| wf_workflow3018    |
| wf_workflow30185   |
| wf_workflow3018b   |
| wf_workflow31      |
| wf_workflow312     |
| wf_workflow3121    |
| wf_workflow313     |
| wf_workflow313e    |
| wf_workflow31b     |
| wf_workflow320     |
| wf_workflow32b4    |
+--------------------+
19 rows in set (0.23 sec)

mysql> use wf_workflow3018;

Database changed
mysql> DELETE FROM AH USING APP_HISTORY AS AH, APPLICATION AS A WHERE A.APP_STATUS='COMPLETED' AND A.APP_UID=AH.APP_UID;
Query OK, 73 rows affected (0.21 sec)
mysql> exit;

[sgkalluri]

Thanks a lot Amos!

Here is what I have done... I estimated that the bulk of the space is occupied by the History_Data field of the App_History table. So, I updated all records of this field to blank values. The result was that the space occupied reduce to a fraction of the original space occupied. The audit trail was retained, however the change log was lost. It is an acceptable compromise as of now.

Thanks once again!

Best wishes,
SGK