As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only. Moving forward, myibi is our community platform to learn, share, and collaborate. We have the same Focal Point forum categories in myibi, so you can continue to have all new conversations there. If you need access to myibi, contact us at email@example.com and provide your corporate email address, company, and name.
What's the current recommendation on Bouncing the Servers? Should that be done periodically, I'm thinking: Yes? Or, what better way is there to maintain the clean functionality of the environments?
Case in point: We just had an issue where things were so slow that AppStudio timed out while accessing the environments. We restarted the associated services and things are working fine now.This message has been edited. Last edited by: Doug,
In FOCUS Since 1983 ~ from FOCUS to WebFOCUS. Current: WebFOCUS Administrator at FIS Worldpay | 8204, 8206
Posts: 3132 | Location: Tennessee, Nashville area | Registered: February 23, 2005
When I was an SE a lot of my customers would recycle the reporting server on a weekly basis. The edatemp directory is re-created every time the server is recycled and it would also clear up any excess memory usage as well.
Francis post is also very valid for cleaning up an agent that may be causing an immediate issue and the server can't be bounced.
Thank you for using Focal Point!
Chuck Wolff - Focal Point Moderator WebFOCUS 7x and 8x, Windows, Linux All output Formats
Posts: 2128 | Location: Customer Support | Registered: April 12, 2005
depends on your usage volume and your tomcat, if you use it. if your edaprint logs get gigantic, recycle more often. if you use tomcat, that sucker needs a recycle as well, renaming the current localhost and starting over with a fresh one when you restart. I learned from techsupport to rename my tomcat localhosts as a.localhost, b.localhost, etc, after stopping the service and before restarting. and as francis says, look for hung agents. I use an includable fex in every report that grabs the name of the fex, the user, some parms, and puts it into a .txt file in the agent, so when something crashes or hangs , I can always tell what broke and who ran it.
In Focus since 1979///7706m/5 ;wintel 2008/64;OAM security; Oracle db, ///MRE/BID
Posts: 3811 | Location: Manhattan | Registered: October 28, 2003
Originally posted by susannah: If your edaprint logs get gigantic, recycle more often.
Just as a side note, you can minimize this by configuring a max line limit and edaprint history file count. You don't have to keep the default edaprint config. For example, you can max the size to 10k lines and 5 history files. It will rollover the edaprints and delete older history files automatically.
"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott
And just a little after posting that we ran into slowness on our DEV server caused by a new version of McCoffee anti-virus, that did not copy the excluded binaries (tscom3, jscom3, edapsomething, tomcat7) nor the excluded directories (not possible anymore?) from the previous version. As a result, it was interfering with the WebFOCUS binaries, severely degrading performance.
And OMG, what kind of user interface is THAT?!? They clearly focused more on pretty pictures than on usability...
WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010 : Member of User Group Benelux :
On Linux, we rarely reboot the server(s). Slowness can be caused by any of the aforementioned issues plus several others. Temporary files (for example, using Excel output) are written to a specific directory which is designated in the Admin Console. We’ve had run-ins with Java memory issues. Just make sure to check your application server log files and you WF log files (client and reporting server) before restarting anything if you want to get to the root problem. I’ve had times where the log files showed nothing suspicious and a recycling of Tomcat fixed the slowness, so, there’s that, too.
I finally decided to look into the forums for the first time in forever. Lo and behold - a post from Doug Lee
Here's the thing nobody's mentioned, the hanging behavior is very likely actually occurring at the WF client level. It's not necessarily the reporting server.
If you bounced both Tomcat and the WFRS services and things started working, it might have been a client issue.
Here's how to tell - next time it occurs, use something like Fiddler or turn on the AS communication layer trace. (essentially they both watch HTTP traffic which AS uses to connect to the environment)
I can help you with that if you need a hand. A hint when using the communication layer trace - leave the utility running and just toggle on or off. The tracing will start or stop instantly. No need to close that utility between starting and stopping tracing. Notice the path it shows for where the trace will land on your machine (wfscom.trc).
For more info see the user manual and or call me.
WebFOCUS App Studio User’s Manual Release 8.2 Version 01 September 22, 2016