Bug 1115454

Summary: BPM produces verbose WARN messages when configured with Oracle 11
Product: [Retired] JBoss BPMS Platform 6 Reporter: Anton Giertli <agiertli>
Component: DocumentationAssignee: Vikram Goyal <vigoyal>
Status: CLOSED NEXTRELEASE QA Contact: Jiri Svitak <jsvitak>
Severity: medium Docs Contact: Vikram Goyal <vigoyal>
Priority: medium    
Version: 6.0.2CC: agiertli, brms-docs, dvanbale, jsvitak, kverlaen, mbaluch, mrietvel, mswiders, ravindra.tubati
Target Milestone: CR2   
Target Release: 6.1.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-04-16 01:33:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Anton Giertli 2014-07-02 12:01:07 UTC
Description of problem:
Without any real actions following log can be found in the log:

13:26:41,319 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss BPM Suite 6.0.2.GA (AS 7.2.1.Final-redhat-10) started in 103025ms - Started 540 of 614 services (71 services are passive or on-demand)
13:26:42,919 WARN  [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes
13:26:45,913 WARN  [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes
13:26:48,912 WARN  [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes
13:26:51,913 WARN  [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes
13:26:54,912 WARN  [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes
13:26:57,912 WARN  [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes
13:27:00,913 WARN  [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes
13:27:03,913 WARN  [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes
13:27:06,913 WARN  [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes
13:27:09,913 WARN  [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes

The BPM is configured to use supported database Oracle 11 and the !!same!! configuration did not produced any logs like this in BPM 6.0.1

Though this error might not be dangerous it is very annoying as these log messages are very very frequent (tens / hundreds of them)

Version-Release number of selected component (if applicable):

BPM 6.0.2 + Oracle 11
How reproducible:

always
Steps to Reproduce:
1. Configure Oracle datasource in JBoss EAP 6.1.1
2. Configure business-central.war to use this datasource (persistance.xml)


Actual results:
messages like this are produced with no apparent reason
13:27:09,913 WARN  [org.hibernate.loader.Loader] (pool-15-thread-1) HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes

Expected results:
no unnecessary WARN messages are produced

Additional info:

Comment 2 Anton Giertli 2014-07-02 12:19:27 UTC
workaround (standalone.xml):
 <logger category="org.hibernate.loader">
                <level name="ERROR"/>
            </logger>

Comment 7 Jiri Svitak 2014-07-14 12:33:03 UTC
I can confirm this issue in BPMS 6.0.2.GA.

Comment 8 Maciej Swiderski 2015-01-16 15:06:18 UTC
This comes form jbpm executor that queries for available jobs with locks. While it tries to get only first available job it will use the first and max result setting on pa query and by that can be seen as doing paging. And because of that it runs into this issue on hibernate side: https://hibernate.atlassian.net/browse/HHH-1168

the reason why it does locking is to minimalize race conditions between executor threads or executor instances in the cluster. Otherwise they might be fetching same job on different threads/server instance of a cluster.

While it does not cause any issues it might cause some race conditions on Oracle due to this follow up locking which happens in second query. Since that is oracle specific we cannot change it to anything that will work same way for all data bases.

I see two options:
1. we stick with what we have now and change logger level for deployments on oracle
2. we change implementation to not lock the result of the query that fetches job to execute and let the executor threads/server instances fail randomly on optimistic lock exception due to multiple threads trying to get the same job for processing.

Personally I am in favor of using option 1 as it brings much better execution semantic on other data base and affects slightly oracle based deployments. While second one will affect all data bases. Moreover second will have higher rate of occurrences when more threads of executor are in use. For default it won't make bigger difference as there is single executor thread running.

Comment 9 Kris Verlaenen 2015-01-16 15:11:57 UTC
I believe that we shouldn't introduce changes in our code base that might have negative effects.  +1 for documenting the logging workaround.

Comment 10 Jiri Svitak 2015-01-20 15:35:42 UTC
*** Bug 1178849 has been marked as a duplicate of this bug. ***

Comment 11 Marco Rietveld 2015-01-20 15:43:40 UTC
This is a common issue with hibernate:

http://stackoverflow.com/questions/22712195/hibernate-warning-about-follow-on-locking-using-oracle-10g

The hibernate team has opened a jira to address this issue: 

https://hibernate.atlassian.net/browse/HHH-9097

Comment 12 Marco Rietveld 2015-01-20 15:45:22 UTC
Jiri or Anton, given comment 11, would it be okay to close this, since it's an issue with Hibernate and not the BPM suite?

Comment 13 Anton Giertli 2015-02-09 08:01:14 UTC
Marco,

I think it would be more suitable to re-assign this to the Doc Team. I would like to see the root cause and the configuration workaround in the Installing or Administration guide. What do you think?

Or you would like to open a new BZ for that?

Anton.

Comment 14 Marco Rietveld 2015-02-09 09:33:18 UTC
Anton, good idea: please do! Thanks.

Comment 15 Anton Giertli 2015-02-09 09:43:34 UTC
Vikram,

I have re-assigned this BZ to you as it requires doc update - either installing or admin guide.

Users needs to be aware that when Oracle DB is used, the verbose logging(as showed in initial description) is expected behavior (as explained in comment 8) with possible workaround as explained in comment 2.

Cheers,
Anton

Comment 16 Vikram Goyal 2015-02-09 09:49:34 UTC
Thanks Anton. Changing component to Documentation.

Comment 18 Vikram Goyal 2015-04-16 01:33:54 UTC
Thanks Anton,

Added a note in the Installation Guide for BPM Suite in the chapter: Setting up Persistence for Business Central. For the 6.1 Guides.

This can be reviewed here [1].

Not setting this to ON_QA but directly to CLOSED-->NEXTRELEASE.

[1] https://documentation-devel.engineering.redhat.com/site/documentation/en-US/Red_Hat_JBoss_BPM_Suite/6.1/html-single/Installation_Guide/index.html#Setting_up_Persistence_for_Business_Central