2Pack Hangs in 7.1+

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.

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.

@Heng Sin Low 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 @Chuck Boecking 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 https://idempiere.atlassian.net/browse/IDEMPIERE-2767, 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