NA Business Team
Category
System Configuration
Product Version
7.1
session time out database
Answered
where in the database is the configuration to set the session time out? i have tried setting the session time out in the web.xml file but it hasn't changed in yellowfin. it is currently set to -60 seconds and we would like to change it.
The same question
Hi Aaron,
Thanks for reaching out. The user session timeout is located in a web.xml file, however, there's more than one web.xml file in Yellowfin's file structure.
I'm guessing since you mentioned the timeout setting in seconds you saw the timeout data in the event table:
But this configuration cannot be altered in the database.
To change this value, you'd do so in the web.xml file found in the <YellowfinInstall>/appserver/conf folder.
If you have an application that has a line count, this value is found on line 582. Otherwise you can just search by "session-timeout" to find the right location:
Hopefully this gives you what you're looking for.
Please let me know if you have any further questions.
Regards,
Mike
Hi Aaron,
Thanks for reaching out. The user session timeout is located in a web.xml file, however, there's more than one web.xml file in Yellowfin's file structure.
I'm guessing since you mentioned the timeout setting in seconds you saw the timeout data in the event table:
But this configuration cannot be altered in the database.
To change this value, you'd do so in the web.xml file found in the <YellowfinInstall>/appserver/conf folder.
If you have an application that has a line count, this value is found on line 582. Otherwise you can just search by "session-timeout" to find the right location:
Hopefully this gives you what you're looking for.
Please let me know if you have any further questions.
Regards,
Mike
would it be possible that Apache tomcat could be controlling this as i have set the session timeout to 60 min and 30 min and it stays at -60 seconds
would it be possible that Apache tomcat could be controlling this as i have set the session timeout to 60 min and 30 min and it stays at -60 seconds
Hi Aaron,
It is indeed Apache Tomcat that's controlling this. The web.xml found in /appserver/conf is a part of the web servers file structure.
The top of that file indicates this as well:
Regards,
Mike
Hi Aaron,
It is indeed Apache Tomcat that's controlling this. The web.xml found in /appserver/conf is a part of the web servers file structure.
The top of that file indicates this as well:
Regards,
Mike
ok so i would need to change the session timeout in Apache for it to change in yellowfin? or should it still follow the web.xml files settings?
ok so i would need to change the session timeout in Apache for it to change in yellowfin? or should it still follow the web.xml files settings?
Hi Aaron,
The Apache web.xml file found in <YellowfinInstall>/appserver/conf is the file that needs to be edited for this change to be picked up by Yellowfin.
Not the web.xml found here:
which is I assume the one you've been looking at.
Regards,
Mike
Hi Aaron,
The Apache web.xml file found in <YellowfinInstall>/appserver/conf is the file that needs to be edited for this change to be picked up by Yellowfin.
Not the web.xml found here:
which is I assume the one you've been looking at.
Regards,
Mike
yes the first one is the one that i have been using, but when changed the yellowfin does not react to the new session timeout and stays at -60 seconds. we are restarting the yellowfin service each time that we change it. also i could not find the event table in the database at all where is it located?
yes the first one is the one that i have been using, but when changed the yellowfin does not react to the new session timeout and stays at -60 seconds. we are restarting the yellowfin service each time that we change it. also i could not find the event table in the database at all where is it located?
Hi Aaron,
Can you send over a copy of your web.xml file?
What is the output of executing the following query?
It should look something like this:Regards,
Mike
Hi Aaron,
Can you send over a copy of your web.xml file?
What is the output of executing the following query?
It should look something like this:Regards,
Mike
i am unable to send the web.xml file as my workplace is very strict on security.
i have found the correct field but it is showing -60 is there anyway to find out where this is getting its timeout numbers from? because they aren't coming from the web.xml file.
i am unable to send the web.xml file as my workplace is very strict on security.
i have found the correct field but it is showing -60 is there anyway to find out where this is getting its timeout numbers from? because they aren't coming from the web.xml file.
Hi Aaron,
What value are you attempting to input? Can you just send a snapshot of the pertinent portion of the appropriate web.xml file then?
Regards,
Mike
Hi Aaron,
What value are you attempting to input? Can you just send a snapshot of the pertinent portion of the appropriate web.xml file then?
Regards,
Mike
any value that brings the session timeout above 0 as we are having issues with users being stuck logged in because of session timeouts. also is there a way to set the user remember settings so i can have it ask if i want to log someone out without kicking them out in this file?
any value that brings the session timeout above 0 as we are having issues with users being stuck logged in because of session timeouts. also is there a way to set the user remember settings so i can have it ask if i want to log someone out without kicking them out in this file?
Hi Aaron,
This certainly seems odd... in more ways than one. In the event table, the value should be in seconds, not minutes, so if the value is set to 60 in the web.xml, not only should the value not be negative, but it should showing "timeout=3600" in the event table. I'm curious as to whether there are errors being generated in the logs. Can you send a compressed copy of your entire logs folder, located at <YellowfinInstall>/appserver/logs?
As for the second part of your most recent question, you can indeed have YF ask whether you want to kill a pre-existing remote session. This setting is found under Administration > Configuration > Authentication > General Settings > Multiple Login Logic:
Does this appear to be what you're looking for?
Regards,
Mike
Hi Aaron,
This certainly seems odd... in more ways than one. In the event table, the value should be in seconds, not minutes, so if the value is set to 60 in the web.xml, not only should the value not be negative, but it should showing "timeout=3600" in the event table. I'm curious as to whether there are errors being generated in the logs. Can you send a compressed copy of your entire logs folder, located at <YellowfinInstall>/appserver/logs?
As for the second part of your most recent question, you can indeed have YF ask whether you want to kill a pre-existing remote session. This setting is found under Administration > Configuration > Authentication > General Settings > Multiple Login Logic:
Does this appear to be what you're looking for?
Regards,
Mike
the value does not change with the event table so if i set it to 45 min it would still show -60 seconds.
as i said earlier i am unable to send the log file. would there be something specific that you would be looking for? maybe i can find it?
for some reason we are unable to access the authentication tab under configuration so i was hoping this setting could be set outside of yellowfin.
the value does not change with the event table so if i set it to 45 min it would still show -60 seconds.
as i said earlier i am unable to send the log file. would there be something specific that you would be looking for? maybe i can find it?
for some reason we are unable to access the authentication tab under configuration so i was hoping this setting could be set outside of yellowfin.
Hi Aaron,
Ah, that's right. I just responded to that ticket with more information. I think I've determined what was happening there.
In terms of this issue, I would be looking at the catalina.out, yellowfinstdout, and yellowfinstderr logs to look for general startup errors. I can't really be more specific than that though as I can't say with much precision what errors may be there. Hopefully something of value is contained in one of those three log files.
Regards,
Mike
Hi Aaron,
Ah, that's right. I just responded to that ticket with more information. I think I've determined what was happening there.
In terms of this issue, I would be looking at the catalina.out, yellowfinstdout, and yellowfinstderr logs to look for general startup errors. I can't really be more specific than that though as I can't say with much precision what errors may be there. Hopefully something of value is contained in one of those three log files.
Regards,
Mike
the yellowfinstdout and yellowfinstderr logs are in the same place as the catalina.out? i couldn't find anything other than yellowfin.log.1, yellowfin.log.2, yellowfin.log.3 ect... in the logs folder. also is the catalina.out usually a large file? mine is capping at 2 GB.
the yellowfinstdout and yellowfinstderr logs are in the same place as the catalina.out? i couldn't find anything other than yellowfin.log.1, yellowfin.log.2, yellowfin.log.3 ect... in the logs folder. also is the catalina.out usually a large file? mine is capping at 2 GB.
Hi Aaron,
Replying for Mike as he's out today. The catalina.out file will contain logs of your startup process. If you can tail -f this file while restarting Yellowfin, we should be able to determine if there's a problem with Tomcat reading your configuration file. If you do find an error during startup, please include them here. Alternatively we can move this over to a private ticket for transferring said information.
Thanks,
Ryan
Hi Aaron,
Replying for Mike as he's out today. The catalina.out file will contain logs of your startup process. If you can tail -f this file while restarting Yellowfin, we should be able to determine if there's a problem with Tomcat reading your configuration file. If you do find an error during startup, please include them here. Alternatively we can move this over to a private ticket for transferring said information.
Thanks,
Ryan
can you give me an example of what i'm looking for in terms of it reading the configuration file? does it look similar to "INFO: Deployment of configuration descriptor /u01/yellowfin/yellowfin/appserver/conf/Catalina/localhost/ROOT.xml has finished in 20,092 ms"?
can you give me an example of what i'm looking for in terms of it reading the configuration file? does it look similar to "INFO: Deployment of configuration descriptor /u01/yellowfin/yellowfin/appserver/conf/Catalina/localhost/ROOT.xml has finished in 20,092 ms"?
Hi Aaron,
I'd guess there'd be some error message before then, if there was one. Specifically within the first 30 seconds or so of the startup process. It's pretty hard to guess at, as there can be many types of messages.
Regards,
Mike
Hi Aaron,
I'd guess there'd be some error message before then, if there was one. Specifically within the first 30 seconds or so of the startup process. It's pretty hard to guess at, as there can be many types of messages.
Regards,
Mike
That's the first thing under the startup and i cant find anything referencing the web.xml file at all.
That's the first thing under the startup and i cant find anything referencing the web.xml file at all.
Hi Aaron,
Without being given access to logs, and considering that this is occurring in 7.1, there's not much more I can attempt on my end to try and resolve this. There's a good chance if you were to upgrade your instance that this issue would be resolved. If upgrading did not resolve the issue though, the only option would be to obtain a full backup of your config db, so I can attempt replication, which I suspect we also wouldn't be able to obtain. If we don't have this possibility available to us there's no way we can investigate, replicate and subsequently raise to the dev team to have a fix developed.
This all said, there is one more aspect I'm curious of: what do you see when going to Administration > Session Management:
What does it say for Timeout? Unknown? -30 seconds? etc.
Finally, there's one last thing I'm thinking can be attempted here that may be worth a shot, if none of what else I've mentioned can be performed, and that would be upgrading just your Tomcat. You can find steps on how to do that in this Knowledge Base article: How to Upgrade Tomcat.
Barring this, our hands are kind of tied if we're stuck troubleshooting an EOL version where you're unable to upgrade, we have no pre-existing logged cases of said error, and we can't be sent logs or config db backups. Either way, please let us know on the Session Management output and whether you'd like to proceed with upgrading Tomcat itself.
Thanks,
Mike
Hi Aaron,
Without being given access to logs, and considering that this is occurring in 7.1, there's not much more I can attempt on my end to try and resolve this. There's a good chance if you were to upgrade your instance that this issue would be resolved. If upgrading did not resolve the issue though, the only option would be to obtain a full backup of your config db, so I can attempt replication, which I suspect we also wouldn't be able to obtain. If we don't have this possibility available to us there's no way we can investigate, replicate and subsequently raise to the dev team to have a fix developed.
This all said, there is one more aspect I'm curious of: what do you see when going to Administration > Session Management:
What does it say for Timeout? Unknown? -30 seconds? etc.
Finally, there's one last thing I'm thinking can be attempted here that may be worth a shot, if none of what else I've mentioned can be performed, and that would be upgrading just your Tomcat. You can find steps on how to do that in this Knowledge Base article: How to Upgrade Tomcat.
Barring this, our hands are kind of tied if we're stuck troubleshooting an EOL version where you're unable to upgrade, we have no pre-existing logged cases of said error, and we can't be sent logs or config db backups. Either way, please let us know on the Session Management output and whether you'd like to proceed with upgrading Tomcat itself.
Thanks,
Mike
we are in the works to upgrade to 7.4 but we need to go through our trial testing first which will take a while. this issue is not terribly important as the issue that was being caused by it was fixed in another way. if there doesn't seem to be a solution in this next step then i think we should just shelve it.
we are in the works to upgrade to 7.4 but we need to go through our trial testing first which will take a while. this issue is not terribly important as the issue that was being caused by it was fixed in another way. if there doesn't seem to be a solution in this next step then i think we should just shelve it.
Hi Aaron,
The good thing is that testing this in 7.4 is as simple as heading to the Session Management page, as of you've done here, to see if it's working properly in that version. But in terms of this still occurring in 7.1, yes, I'm afraid our hands are tied at this point. If this does still occur for you in 7.4, we can certainly discuss further options - perhaps reaching out to the appropriate parties to discuss making an exception in getting us a config db backup, or some other arrangement, but we can cross that bridge when we come to it.
Either way, please let us know whether you'd like to shelve this for now or attempt a Tomcat upgrade first.
Regards,
Mike
Hi Aaron,
The good thing is that testing this in 7.4 is as simple as heading to the Session Management page, as of you've done here, to see if it's working properly in that version. But in terms of this still occurring in 7.1, yes, I'm afraid our hands are tied at this point. If this does still occur for you in 7.4, we can certainly discuss further options - perhaps reaching out to the appropriate parties to discuss making an exception in getting us a config db backup, or some other arrangement, but we can cross that bridge when we come to it.
Either way, please let us know whether you'd like to shelve this for now or attempt a Tomcat upgrade first.
Regards,
Mike
we have a sandbox server that we need to test on before we can upgrade which is currently down, we wont be upgrading tomcat anytime soon as that would affect a lot more than just yellowfin. but i did notice that i can not delete the session data for the session on the session management page, could it be that yellowfin does not have read/write permission on the database end?
we have a sandbox server that we need to test on before we can upgrade which is currently down, we wont be upgrading tomcat anytime soon as that would affect a lot more than just yellowfin. but i did notice that i can not delete the session data for the session on the session management page, could it be that yellowfin does not have read/write permission on the database end?
Hi Aaron,
That's understandable re: Tomcat. In terms of the Session Management aspect, you can't Delete your own session, so in the example from your screenshot, you should be able to check the box for the top result for System Administrator and Delete that session.
If you cannot, then I suppose it's possible there is some sort of permissions issue. I suspect something would be generated in the standard Yellowfin log upon clicking Delete. Can you check on that?
Regards,
Mike
Hi Aaron,
That's understandable re: Tomcat. In terms of the Session Management aspect, you can't Delete your own session, so in the example from your screenshot, you should be able to check the box for the top result for System Administrator and Delete that session.
If you cannot, then I suppose it's possible there is some sort of permissions issue. I suspect something would be generated in the standard Yellowfin log upon clicking Delete. Can you check on that?
Regards,
Mike
yeah the system admin above mine when i delete it it just pops back up session time intact so its not getting deleted.
it seems that yellowfin doesn't even create the delete event as there are no "JDBCEventCreation:createEvent" in the log file that have "EventCode=KILLSESSION". there is only 3 events (log on and system tasks) in the log file on the server that is having this issue where as the other server that will delete the active session has those before a delete query.
Example of the event that runs on the server that actually deletes the session:
(JDBCEventCreation:createEvent) -EventId=317478,Time=####,SessionId=####,EventTypeCode=REPORTADMIN,EventCode=KILLSESSION, ect...
what could cause the "JDBCEventCreation:createEvent" to not run? there are no errors either its like its not even asked to run.
yeah the system admin above mine when i delete it it just pops back up session time intact so its not getting deleted.
it seems that yellowfin doesn't even create the delete event as there are no "JDBCEventCreation:createEvent" in the log file that have "EventCode=KILLSESSION". there is only 3 events (log on and system tasks) in the log file on the server that is having this issue where as the other server that will delete the active session has those before a delete query.
Example of the event that runs on the server that actually deletes the session:
(JDBCEventCreation:createEvent) -EventId=317478,Time=####,SessionId=####,EventTypeCode=REPORTADMIN,EventCode=KILLSESSION, ect...
what could cause the "JDBCEventCreation:createEvent" to not run? there are no errors either its like its not even asked to run.
Hi Aaron,
An event not being triggered could be caused by any number of things. I couldn't say why this would be occurring with any kind of accuracy without having a reliable replicable environment and steps to take to investigate and test with, and really, since this is not expected, and also apparently defective, behavior, it would ultimately wind up coming down to the dev team to develop fixes. Unfortunately, we're still in the same place we were before this aspect as I don't think this additional info makes it so we take this case any further. It was worth a shot just to try and see though, at least. I strongly suspect this aspect will be okay in the 7.4 sandbox environment you'll be testing in shortly, since this is not an issue we've seen before.
Regards,
Mike
Hi Aaron,
An event not being triggered could be caused by any number of things. I couldn't say why this would be occurring with any kind of accuracy without having a reliable replicable environment and steps to take to investigate and test with, and really, since this is not expected, and also apparently defective, behavior, it would ultimately wind up coming down to the dev team to develop fixes. Unfortunately, we're still in the same place we were before this aspect as I don't think this additional info makes it so we take this case any further. It was worth a shot just to try and see though, at least. I strongly suspect this aspect will be okay in the 7.4 sandbox environment you'll be testing in shortly, since this is not an issue we've seen before.
Regards,
Mike
Hi Mike,
i think it may have just been the way it was installed in our system, so I guess we will just work towards upgrading the product.
Thanks,
Aaron
Hi Mike,
i think it may have just been the way it was installed in our system, so I guess we will just work towards upgrading the product.
Thanks,
Aaron
Hi Aaron,
Thanks for letting us know. Should you run into any issues upon upgrading, with this or anything upgrade related, please don't hesitate to reach out.
Regards,
Mike
Hi Aaron,
Thanks for letting us know. Should you run into any issues upon upgrading, with this or anything upgrade related, please don't hesitate to reach out.
Regards,
Mike
Replies have been locked on this page!