Questions and discussion about developing processes and programming in PHP, JavaScript, web services & REST API.

Moderators: ArturoRobles, ArturoRobles

Forum rules: Please search to see if a question has already asked before creating a new topic. Please don't post the same question in multiple forums.
By danielcorrea
#788200
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
Attachments
History_table.png
History_table.png (50.69 KiB) Viewed 3682 times
User avatar
By amosbatto
#788207
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?
By danielcorrea
#788243
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???
User avatar
By amosbatto
#788244
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.
By StephanS
#788479
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...
By StephanS
#788509
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... )
User avatar
By amosbatto
#788525
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?
By StephanS
#788545
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
By sgkalluri
#793128
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
User avatar
By amosbatto
#793142
sgkalluri wrote: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;
By sgkalluri
#793155
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

I have a suggest where user have to select some do[…]

The 500 Internal Server Error is the general catch[…]

Really very nice blog information for this one and[…]

This is a long, lengthy and cumbersome process. T[…]