Bug 724798 (BRMS-638)

Summary: Repository initialization fails with ModeShape
Product: [JBoss] JBoss Enterprise BRMS Platform 5 Reporter: Jiri Locker <jlocker>
Component: BRM (Guvnor), ModeshapeAssignee: Tihomir Surdilovic <tsurdilo>
Status: VERIFIED --- QA Contact: Jiri Locker <jlocker>
Severity: urgent Docs Contact:
Priority: urgent    
Version: BRMS 5.2.0-Dev1CC: atangrin, jlocker, kurt.stam, kurt.stam, ldimaggi, lpetrovi, psiroky, rhauch, vhalbert
Target Milestone: ---Keywords: TestBlocker
Target Release: BRMS 5.2.0.GA   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/BRMS-638
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=724784
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Encountered with MySQL 5.1, MS SQL 2008, Oracle 11g R2. Not encountered with DB2 and PostgreSQL 8.4.
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 724693    
Description Flags
server.log with hibernate INFO
server.log with a recent Modeshape (BRMS 5.2.0 ER2)
Modeshape configuration used none

Description Jiri Locker 2011-07-13 07:34:49 EDT
Affects Testing: Blocks Testing
securitylevel_name: Public

Exception is thrown during repository initialization, BRMS fails to deploy.
Comment 1 Jiri Locker 2011-07-13 07:35:32 EDT
Attachment: Added: server.log
Comment 2 Jiri Locker 2011-07-19 04:21:38 EDT
Affects Testing: Added: [Blocks Testing]
Comment 3 Randall Hauch 2011-07-19 11:50:08 EDT
It's strange that it works for some DBMSes but not others. Could this be due to the differences in transaction isolation level? That kind of makes sense that the database needs a bit more liberal isolation.

I'd suggest changing the isolation level for Oracle or MySQL, and trying again. If that works, then try it for the other two DBMSes.
Comment 4 Randall Hauch 2011-07-20 10:11:13 EDT
Assigning to Kurt as he requested: "I would say the only way is to reproduce it in an integration test to reproduce, so that we can isolate and understand the issue, then if it turns out to be a ModeShape issue we can ask Randall for help. Please assign to me and i will take a look. It'd be great to have a debug trace of this as well."
Comment 5 Randall Hauch 2011-07-20 10:13:16 EDT
Link: Added: This issue relates to BRMS-622
Comment 7 Len DiMaggio 2011-07-20 14:39:44 EDT
Link: Added: This issue relates to BRMS-646
Comment 8 Jiri Locker 2011-07-22 09:48:15 EDT
Created attachment 514701 [details]
server.log with hibernate INFO

I've attached server log containing hibernate logging at INFO level. I find these entries interesting:

2011-07-22 15:23:48,478 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (modeshape-start-repo-2-thread-1) Running hbm2ddl schema export
2011-07-22 15:23:48,479 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (modeshape-start-repo-2-thread-1) exporting generated schema to database
2011-07-22 15:23:49,368 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (modeshape-start-repo-2-thread-1) Unsuccessful: create table DNA_CHANGELOG (ID bigint not null auto_increment, CHANGES longblob not null, CHANGE_COUNT integer not null, UTC_TIMESTAMP bigint not null, USERNAME varchar(64) not null, primary key (ID)) ENGINE=InnoDB
2011-07-22 15:23:49,369 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (modeshape-start-repo-2-thread-1) You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'UTC_TIMESTAMP bigint not null, USERNAME varchar(64) not null, primary key (ID)) ' at line 1
2011-07-22 15:23:50,358 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (modeshape-start-repo-2-thread-1) Unsuccessful: create index NS_CHANGE_TS_INX on DNA_CHANGELOG (UTC_TIMESTAMP)
2011-07-22 15:23:50,358 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (modeshape-start-repo-2-thread-1) You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'UTC_TIMESTAMP)' at line 1
2011-07-22 15:23:51,866 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (modeshape-start-repo-2-thread-1) schema export complete
Comment 9 Jiri Locker 2011-07-22 09:53:41 EDT
Created attachment 514706 [details]

Also attaching org.modeshape DEBUG output.
Comment 10 Kurt T Stam 2011-07-22 10:24:20 EDT
Jiri, just double checking that the Mysql5 dialect is being set in the hibernate config? --Kurt
Comment 11 Van Halbert 2011-07-22 11:07:22 EDT
The problem is in the use of UTC_TIMESTAMP as a column name.   The column name is being renamed.   Also, since this table is no longer used, it is being deprecated.
Comment 12 Kurt T Stam 2011-07-22 11:11:04 EDT
So it looks like this issue is caused by a modeshape column naming issue:
https://issues.jboss.org/browse/MODE-1225. I'm assuming the same is
true for the other databases this issue is reported on.

Comment 13 Randall Hauch 2011-07-25 12:25:49 EDT
A fix for MODE-1225 has been committed into the '2.5.x' branch currently used for the 5.2 products, so it should appear in the next build.
Comment 14 Ryan Zhang 2011-07-27 02:41:05 EDT
I would pick up in the next build BRMS 5.2 ER2
Comment 15 Kurt Stam 2011-07-28 10:47:14 EDT
FYI: BRMS depends on the ModeShape service, so it is a runtime dependency only; You don't have to wait for a new BRMS build to upgrade the ModeShape service.
Comment 16 Van Halbert 2011-07-28 10:58:09 EDT
ModeShape was rebased yesterday into git.app and a mead build was done.
Comment 17 Jiri Locker 2011-08-03 09:30:03 EDT
The latest ModeShape build fixes MODE-1225 (failing schema export due to UTC_TIMESTAMP column), but we still get the exception during jboss-brms.war deployment. The exception can be view in the attached server.log.
Comment 18 Randall Hauch 2011-08-03 10:13:05 EDT
I don't see the log file. With the fix, there is no longer a UTC_TIMESTAMP column, and in fact the table in which the column appears should no longer appear in the schema. As a result, I'm not convinced your using a ModeShape build containing the fix.
Comment 19 Jiri Locker 2011-08-03 10:30:08 EDT
Sorry, I haven't probably made myself clear enough.

Firstly, we confirm that MODE-1225 is fixed in the latest ModeShape build, that Van is referring to in comment 16.

Secondly, we still encounter the exception contained in attachment 514566 [details]. That means the bug reported in this bugzilla is not directly caused by MODE-1225 and the real cause needs to be looked fore somewhere else (might not be a ModeShape bug at all). That's why I have already assigned back to Tihomir to conduct further investigation.
Comment 20 Lukáš Petrovický 2011-08-12 10:43:39 EDT
Created attachment 518041 [details]
server.log with a recent Modeshape (BRMS 5.2.0 ER2)

Attaching a recent server.log
Comment 21 Lukáš Petrovický 2011-08-12 10:44:33 EDT
Created attachment 518042 [details]
Modeshape configuration used
Comment 22 Lukáš Petrovický 2011-08-12 10:46:08 EDT
I should mention that server running on top of Oracle 11g was used to generate these past two attachments.
Comment 23 Van Halbert 2011-08-12 11:15:57 EDT
MODE-1225 has been resolved and should be in the next build.     This was an issue with Oracle and PostreSQL.
Comment 24 Lukáš Petrovický 2011-08-14 12:01:31 EDT
Jirka already explained the situation in comment 19 - we know that the issue is fixed *AND* repository initialization still fails with Modeshape. Please see attachment 518041 [details], which is the current manifestation of the problem.

If you wish, we can close this bug and file a new one for this new problem.
Comment 25 Van Halbert 2011-08-24 20:39:04 EDT
Commit ID:   24938f14255fdc2a037a
for MODE-1245 was committed to the 2.5.x branch to resolve the ItemNotFoundException that is occurring at start up time.    

This should be available for the next BRMS ER3 build.
Comment 26 Lukáš Petrovický 2011-08-31 09:14:52 EDT
This bug is now fixed. Thanks!