Admintool Check-in changes: Internal Assertion Error Condition

Creating a pivot table view with mixed granularity
November 10, 2009
OBIEE heats up, OBIEE blogging cools down
November 30, 2009

If you’re running OBIEE under 64-bit Solaris – this might be of use. I just want to add from myself – that it’s not a good idea to change repository in online mode.

Admintool Check-in changes: Internal Assertion Error Condition FALSE , file server/Utility/Generci/NQThreads/SUGThread.cpp, line 515 [ID 820803.1]

When checking in changes in Admintool, you are getting the error:

nQSError:28019 Near line 230: In the metadata expression … the following error occured nQSError 46036 Internal Assertion Error Condition FALSE , file server/Utility/Generci/NQThreads/SUGThread.cpp, line 515
Cause

This is a defect:
Bug 6652490: PSR:FUNC:ESSBASE: OBSERVED THE ERROR WHILE CHECK-IN OR SAVING RPD IN ONLINE MODE ?

Bug was logged for 10.1.3.3.2 with OBI server on Solaris 64 bits

Although the abstract mentions Essbase the bug is reproducible against any database.
But only when OBI is on 64 bits solaris platform.
It applies to all versions from OBI 10.1.3.3.1 and later.

Test case:
From Admin tool created the new rpd (i.e. physical layer) and Drag-Drop
the db to Business model & Presentation layer then tried to Check In / Save
form Admin tool in Online mode but I observed the below error form Admin tool
window as well as NQServer.log
Error Message:
[46036] Internal Assertion: Condition FALSE, file server/Utility/Generic/NQ
Threads/SUGThread.cpp, line 515.
2007-11-27 04:44:12
[46036] Internal Assertion: Condition FALSE, file
server/Utility/Generic/NQ
Threads/SUGThread.cpp, line 515

Off line mode able to check-in or saved sucessfully.

Also we only had the error on a Business Model that had been dragged and dropped from the physical.
Solution
The workaround is to modify the NQSConfig.INI file.
Change the “SERVER_THREAD_STACK_SIZE = 0;”
with “SERVER_THREAD_STACK_SIZE = 512 KB;”

and restart the OBI server

Increasing thread stack size (by setting SERVER_THREAD_STACK_SIZE to a bigger number) is the solution to this issue in all versions including 10.1.3.4.

Increasing thread stack size requires more memory from the server machine.
That is the only impact it should have. But increasing from 256k (default) to 512k is a minor change

This defect will be fixed in the next main release

1 Comment

  1. m says:

    Have same error on winxp sp3 on 10.1.3.4. This param didn’t solve error.

Leave a Reply