2Pack Hangs in 7.1+

Description

The below packin was created in 3.1, and it has worked all the way through 6.2. Starting in 7.1, the pack in process simply hangs with no descriptive error. I am happy to sponsor to fix this issue.

https://github.com/chuboe/idempiere-installation-script/tree/master/apps/AdvancedSearch

This issue was confirmed in many environments including iDempiere6.2 (worked), logilite 7.1 (failed), and test.idempiere.org (failed).

If you do not want to fix, that is OK. just let me know, and I will create a 6.2 environment, create a new pack in then pack out to help potentially resolve the issue.

Thank you!
Chuck Boecking
www.chuckboecking.com

Environment

7.1+

Activity

Show:
Carlos Ruiz
February 10, 2021, 2:57 PM

Ready, decreased the log level to INFO, and added a javadoc note to the default MRole constructors.

The thing is that in some cases people read a role to check for permissions, using an MRole constructor instead of a get has undesired effects.

Heng Sin Low
February 10, 2021, 4:29 AM

The confusion for me here is if it is “valid” for certain use cases, why it is log as “warning” ?

For me, warning means you should change the code to avoid it from happening again.

Carlos Ruiz
February 8, 2021, 2:14 PM

wrote:

Hi @CarlosRuiz-globalqss ,

What's the root cause of this ?

This looks more like a workaround than a fix to me.

Regards,
Low

 

answering here:

Well, I knew the problem:

  • log.severe is a cause of contention in many classes because it does an insert into AD_Issue, simple solution is to change to log.warning, but then you don’t have the error registered in AD_Issue

But, because of your question I went deep to find the root cause:

  • The 2pack provided by here has several ALTER TABLE R_Request, this command creates a lock for the table R_Request

  • When calling log.severe it tries to insert into AD_Issue table without transaction, this table has a foreign key pointing R_Request

  • It seems that the lock on R_Request that the alter imposes doesn’t allow to solve the foreign key validation and the command is stuck there

So, extending from that:

  • any program that executes an ALTER table in one of these tables: A_Asset, AD_Form, AD_Process, AD_Windows, R_IssueProject, R_IssueSystem, R_IssueUser, R_IssueKnown and R_Request (foreign keys from AD_Issue) cannot trigger a log.severe because it will got stuck until the ALTER is committed or rolled back

The log.severe in MRole to annotate "Trying to load Child Roles but user has not been set" was added by me in , and now knowing that the problem is “valid” in certain cases, the log.severe is too high for this, a log.warning can be enough.

Regards,

Carlos Ruiz

Fixed

Assignee

Carlos Ruiz

Reporter

Chuck Boecking

Labels

None

Tested By

None

Components

Fix versions

Affects versions

Priority

Minor