Tag: bugs

Javascript

Quickie: The user is already authenticated in all available namespaces

| cognospaul

Have you ever stepped away from your computer for just a few minutes, and come back to Cognos proudly stating that you’re already logged in? That very useful message preventing you from saving the report that you’ve worked for hours and hours on.

already authenticated

Can you guess what happened to me this morning?

Well, after a few moments of panicking I realized that the reports are still there in the browser. I’m not sure which reports are saved (all of them, right? because I always save when I should), but at least the XML is there waiting for me.

Fortunately, the application JavaScript we need is not obfuscated. So this will work:

for(var i=0;i<frames.length;++i){
if(!frames[i].Application.GlassView) continue;
var gv = frames[i].Application.GlassView
  , saved = gv.isDirty()?'Not Saved':'Saved'
  , name = gv.getTitle()
  , cmProp = gv.cmProperties;

console.log(name + ' is ' + saved)
if(gv.isDirty()&&cmProp){
console.log('In order to save ' + name + ' , type in frames['+i+'].Application.Save() or you can get the report XML by typing frames['+i+'].Application.Document.GetReportXML()')
}
else if(gv.isDirty()&&!cmProp){
console.log('This is an unsaved report so a simple save action will not work. You can retrieve the report xml by typing frames['+i+'].Application.Document.GetReportXML()')
}
}

Run that from the top frame in the console and follow the instructions for each report.

Now a colleague did mention that sometimes pressing the back button will resolve it, but it doesn’t always work for me and I’m super paranoid about losing work.

Uncategorized

BmtActionsHelper.cpp(500) crash when trying to delete an object in Framework

| cognospaul

Ever since the upgrade to 10.1.1, many developers have been reporting an issue with Framework Manager. At some point during the development, Framework suddenly starts crashing whenever they delete or move specific items from the model. Frustratingly, trying to fix the issue by importing the model into a new model tends to copy the same problem.

The error in question is as follows:

Invariably, the developers would be frothing at the mouths because either they forgot to save their changes when it crashed, or they have saved their changes, and now they don’t have a way to revert back to before it started crashing like this.

The manifestation of the bug tends to follow a similar pattern. The models are generally complex, old, and contain more than one package. Some models that exhibit this bug have security, and some don’t. Deleting some fields trigger the bug, and some fields don’t. However, because the crash only happens with specific data items, it makes it easier to track down where the problem is.

In this case, a simple verify model explains what the issue is:

A glance at the model.xml shows that, somehow, there are two security views with the same name.

The easiest way to fix the problem is to delete one of the duplicated securityView nodes. There is a risk that Framework will continue to crash if the remaining securityView contains references to deleted objects, so at the very worst you can paste in:

<securityView><name>GO Sales (query)</name><definition/><access/><functionSets/></securityView></securityViews>

If this happens, you will have to redefine the package definitions, but at least the model will be viable again.

EDIT: Lose your work after the crash? See here on how to recover everything!

10

Content Manager Memory Leaks-Guest Post

| Nimrod (Rod) Avissar

 

Some time ago Paul and I were working together as Cognos Infrastructure specialists for a certain company. During that time, one day the Cognos development environment became unstable, and we were struggling to get it up and running again.

After the day’s events I wrote an email explaining these events to the company’s developers. At Paul’s request I am publishing the main points from this email here. I think they can be educating for a particular sort of Cognos instability, often seen in dev environments.

Mostly, I’m talking about crfashes which are a result of Cognos’ Content Manager reaching maximum memory, and then shutting down. Without the CM there can be no authentication, without authentication there’s no navigation. Also, when a server reaches maximum available memory, it will become slow and non-responsive.

 There are several reasons why a CM Server would max out on memory. One of them is a bug in Cognos 10.1.1 to be fixed in the nearest fix pack (This is really a Java bug, and the JRE was updated in FP1). This bug causes a “Java.Lang.OutOfMemory” error on login. It’s a slow, steady memory leak that breaks out every now and again.

Another well documented reason for a CM server to crash and burn for lack of memory is when requests are piled up in the memory faster than the memory cleans itself. Imagine the following scenario: A report executes the same query 50 times. The query has an error, so the error is written to the log and also to the audit database. The CM is in charge of Audit, so the CM gets 50 requests for Audit update in less than a minute from this report. The CM keeps all these requests in memory, where they are kept not until they are performed, but until the memory is cleaned. This behavior is a result of the requests being stored the Cognos Java process, which is only cleaned once every n minutes.

Now, the developer running the report gets an error or false data, makes a slight change and runs it again. And so on.

If the CM’s memory get filled before a cleanup is made, the CM will max out and will pretty much play dead.

It is very difficult to say, just by analyzing Cognos’ logs, which report or group of reports are responsible for this. If you work with a few developers, it’s not tough to cooperate with them to find the culprits. But the case may be that you’re working with dozens of developers, some not even on site. However, not all hope is lost. You can scan the logs looking for reports that were run over and over and resulted in errors to the logs. To verify, try hiding suspected reports via security, and see what happens. If this works, you’ll have to have a talking-to with the report’s developer. Luckily, since you hid their reports, they are likely to contact you, so you don’t have to search for them.

And as for developers, as a general rule, if an environment is unstable and you are running reports that have been recently developed or that get stuck whenever you run them or that return error messages, the two things may be connected. Your report might, unintentionally, be causing the instability. Alert whoever it is you need to alert.

 

The author, Nimrod Avissar, is a Cognos Architect and Cognos Team Leader at Data-Mine Israel.