API request returns return code 500, user access token is ok

Hi Deepak,

I know that it works in principle. It also works in one environment.
In the newly installed QA environment, unfortunately, it does not work and I can not see any reason in the return code 500.

I query the data with a GET => GET http://<fqdn>/api/admin/users

Do I have to enable the API retrieval somewhere? Does this only work with https? What else causes the error message with JWTVerifier.init?

;) Stefan

Hi Stefan,

I am not really sure of JWT token message. Did the message came from YF log? Could you please share the stack trace if any?

Also, I have requested to test this on Postman because we would understand if YF itself isn't responding at this endpoint or if anything else in between doesn't want us to fetch the results using this API?

Also, do we have any other APIs configured(with a different endpoint) in this environment that are working as expected?

I think Admin Console-->Roles--> is the only place where we enable function related to web services:

Thanks,

Deepak

Hi Deepak,

if it were that simple ;( There is no log output other than these two entries from access.log:

POST /api/refresh-tokens HTTP/1.1" 200 1925
GET /api/admin/users HTTP/1.1" 500 315

With the first query I get the token and the 2 query already returns the 500 error. The token is correct in any case, because if I change it, I get the message "invalid token".

Please ask someone who knows the API to give the right hints. Is there somewhere I can change the log level to debug to generate more log output. Don't know if that would help, because a 500 error is about the worst thing that can happen server-side.

;) Stefan

Hi Stefan,

Unfortunately, Status 500 wouldn't provide more information on what went wrong(Other than internal server error message). We can enable debug logging https://community.yellowfinbi.com/knowledge-base/article/how-do-i-turn-on-debug-logging-within-yellowfin-log-file.

Please share the logs after replicating the same.

We are able to fetch the access token - so the user does have permission tp use Web services. May be its only the /api/admin/users that is causing the trouble? . Can you try accessing any other endpoint for example: /api/reports or /api/data-sources just to verify that this user + access token generated aren't the problem but its the endpoint /api/admin/users .

Thanks,

Deepak

Hi Deepak,,

it affects all calls (500-error), if I misspell in the URL (/api/data-sourcesXX) then I get a 404 (not found).
So I reach the server, only processing API request - except api/refresh-tokens (200 OK) deliver a 500 internal server-error.

I'll upload the logs in a moment. Could you write me again the upload link. In parallel I'm looking for it too, let's see who is faster ;)

;) Stefan

so, I changed the Log4j2.xml, but not one line is logged additionally, not one line with "DEBUG" as log level.

For info, I use an OOB installation without any customization and embedded TC. Are you sure the information is still up to date?

;) Stefan

Hi Stefan,

Yes, we need to change the root level logging to DEBUG and save the file.

For Yellowfin 8.0.8, 9.4 and above:

Find the file log4j2.xml, located at:

Yellowfin/appserver/webapps/ROOT/WEB-INF/log4j2.xml

Towards the bottom of the file, find the line:

<Root level="INFO">

And modify the line to the following:

<Root level="DEBUG">

Save this file and Yellowfin will pick up the change and start DEBUG logging in a minute or two. Debugging information will now be logged to yellowfin.log, along with all the information that was previously logged.

I think we will find debug logs - yellowfin.log file /catalina.out / yellowfin-stdout (depending on how we run YF). But I am not sure if we have a debug level logging for web services calls that we make.

FTP link to upload logs: https://ftp.yellowfin.bi/ and share the name of the file uploaded.

Thanks,

Deepak

HI Deepak,

that's exactly how I implemented it, but the logging doesn't change. No detailed level appears as INFO in the log files.

I do not understand the behavior and it is not the first TC I install/configure and run.
Are we talking about the same file? does this file exist somewhere else? Have you tried it yourself and do you see DEBIG entries?

;) Stefan

Hi Stefan,

I have enabled the debug logs, and then hit the api en point in my local. Here is what I see in the Tomcat:


The same will also be recorded in yellowfin.log files (If we are using startup.bat - windows to run YF, if not then it would be in catalina logs for linux) If we are running it as windows service, then yellowfin-stdout/yellowfin-stderr are the files we should be looking at.

Thanks,

Deepak

Hi,
exciting, I can enter what I want and nothing changes. Since we know TC well, I suspect that the structure of log4j2.xml in the freshly installed version 9.8.1.x was not correct. This would at least explain that nothing changes after changes.
In our case the file looks like attached, please check it against your file

;) Stefan

Hi Deepak,

I had actually replied yesterday, but my post is gone?! OK, maybe I have not pressed save again after uploading ;(

I can not explain it, I'm sure I can change the word "INFO" to "DEBUG".

But I can also enter

<Root level="DARTH VADER"> and nothing changes, no debug, no Darth Vader, just LogLevel "INFO".

I am sure that the file is not used in my Linux Installtion or the structure is not correct. Please try the attached file on your system and check the Linux files.

;) stefan

Hi Stefan,

I don;t actually see any difference between the log4j file on my environment (every latest version of YF would have leog4j.xml but only few old version like YF7xx would have a different log4.properties file)

Attached is the log42.ml from my instance for reference.

Can we try installing a fresh YF (may be with the default HSQL db) on the same server and try to access the api end point via a postman to test if its working? If yes, then we can change the web.xml settings of this fresh installation to point to the db of our current instance.

Thanks,

Deepak

Hi Deepak,

I can't set up a new installation for every problem. Let's clarify in the first step why the log4j2 file does not work in an oob Linux installation. I can put wrong content in it, I can rename the file, nothing changes. I'm sure you're testing on Windows, right?

I specially scheduled an external Linux and Tomcat expert 4 hrs yesterday and it definitely doesn't work.

His explanation: With the global standard class it would work for sure, you use an own yellowfin class for logging. There it does not work.

Please ask someone who knows Tomcat/YF under Linux. So that we can get further. After all, 90% of my messages are actually errors at your end. It will be the same here.

;) Stefan

Hi Stefan,

Yes, I have tested this on my Windows.

Thanks for you involving an external Linux/Tomcat expert. The reason for asking to try setting up a new YF install is because you have mentioned that it worked fine in another environment?

Comments: "I know that it works in principle. It also works in one environment.

In the newly installed QA environment, unfortunately, it does not work and I can not see any reason in the return code 500."

Could you please confirm if the other environment where it is working fine is windows? And you are having issue only with this QA environment which is running on Linux - All other Linux/windows instances are working fine (For DEBUG logging and also APIs)? (Could you please share the info.jsps of both the environments)

And coming to the log4j2 of yellowfin, if the log4j2 file wouldn't work then it shouldn't be logging the INFO logs as well - this is where I am confused. Could you please let me know if we can jump on a call to look at this? I am usually available between 9-5 AEST(Melbourne)

Thanks,

Deepak

Hi Stefan,

Hope you are having a good week.

Just want to check-in and see how things are going as I couldn't hear back from you.

Regards,

Deepak

Hi Stefan,

Hope you are having a good week.

Just want to check-in and see how things are going as I couldn't hear back from you.

Regards,

Deepak

Hi Deepak,

that's funny , I had already replied, but apparently not saved or not waited long enough.

Anyway, I can show you our system with the log problem with pleasure. We only use Skype and I have to invite you or I'm not allowed. Please give me your email address and I will invite you next week. After that I will be on vacation for 3 weeks.

BTW: we don't use windows servers for Yellowfin

;) Stefan

Hi Stefan,

No worries, I am usually available between 9-5 AEST(Melbourne time), please let me know if there is any suitable time slot.

My email address: mehar.chaganti@yellowfin.bi

And is there any difference between the linux servers? (Server on which we don't get 500 error vs server on which we get this error?) Like java versions etc?

Thanks,

Deepak

Hi,

I am now on vacation for 3 weeks, so our appointment will take a while.

I am looking forward to solving the logging problem together. I need that for almost all cases. We will look at the 500 error afterwards.

Please leave the ticket open until then

:) Stefan

Hi Stefan,

Sure, I am happy to jump on a call to discuss the scenario.

Regards,

Deepak

Hi Deepak,

we had a meeting on this case today at 08:30 CEST, claims my calendar ;) You must have had another important appointment, no problem.

I have a good news and a bad news. I'll start with the good news: After the update to v9.9.0, the REST API works in this environment. I can't explain it, before the update it didn't work and there were no other changes. Strange, but never mind.

The bad news: the missing DEBUG logging is clearly a bug in the YF software. I had made a copy of the log4j2.xml file in the same folder "log4j2.xml_bckp_oob" before adjusting the log level and then adjusted the log level in log4j2.xml. But YF uses on the "log4j2.xml_bckp_oob" file and there is ever INFO in it. This must not be technically so.

I do not know how your system determines the correct configuration file. Normally this is done by the complete file name "log4j2.xml". But this is not the case with you.

Should I open a new case for this or can you create a corresponding defect?

;) Stefan

Hi Stefan,

Apologies, that I got caught up with another issue. Please let me know if we can coordinate another time?

Sorry for the inconvenience. I am happy to jump on a call now, if you are free.

Thanks,

Deepak

Thanks for the update on both good and bad news :)

I think we shouldn't keep any other log4j.xml files in the same folder. Could you please try removing all the backup files to a different folder and change the root level logging to DEBUG in the only log4j.xml file?

Please let me know how that goes.

Regards,

Deepak

Hi Deepak,

I don't see your last comment here, unfortunately:

"

I think this is where you are wrong. log4j2 looks for an exact filename if YF has not intervened there. Here is an excerpt from the log4j documentation. I'm opening a new ticket for this, because it's imperative to fix the problem and keep the standard.

if a JSON file cannot be located the XML ConfigurationFactory will try to locate log4j2.xml on the classpath.

Hi Stefan,

Yes, I agree, only the file with name log4j.xml should be picked up. But I think its worth a try to check if this is working (by removing all the older log4j files - including any log4j.property file that comes with older version of YF and then change the root level in log4j2.xmlto DEBUG + restart YF)

And apart for the above suggestion, can we also try looking for log4j core and api jar files in : \appserver\webapps\ROOT\WEB-INF\lib folder

(I think without the above files, it wouldn't even log the INFO level logs, but just wanted to double check)

Thanks,

Deepak

Hi Deepak,
that's how I found out that it's because of that. I had removed the file from the directory and then it works. As a workaround OK, but not a general solution for the error in YF. I have the problem so with no other application and log4j2.

;) Stefan

The lib directory is fine. I check the directories after each update.

Thanks for your support, you can close the ticket. I'll open a new ticket with the log4 error.

Hi Stefan,

Apologies, I misinterpreted that the suggested workaround(to remove other log4j files) didn't help. Thanks for the update that the workaround is positive.

I will go ahead and mark this as completed. Please feel free to get in touch if there is anything that we can help you with.

Warm Regards,

Deepak