Just wanted to put this out there to see if anyone was experiencing similar…
Once a week, we are needing to login to Open Edge Management Console and restart Epicor905Print, Epicor905ProcessServer and Epicor905TaskAgent.
If we don’t do this, we find that when a user runs a front end report, it doesn’t print / print preview - it simply sits in scheduled tasks.
NOTE: We used to run MRP on a schedule and we thought this was causing the problem, but after stopping the schedule and running MRP manually i’m still finding i need to restart these app servers.
Are other companies facing similar issues?
Any comments / feedback would be much appreciated.
aidacra
(Nathan your friendly neighborhood Support Engineer)
7
in the Experts’ Corner I’ll post my Advanced Epicor 9.05 troubleshooting presentation which goes through some of the tools and techniques that are needed to get to the root cause.
But, some key things:
nothing should be on a startup scheduled task in the System Monitor. I know that startup exists and I know that some recommend its use, but, most issues with schedules have to do with using that schedule type. NOTE: If you are using Epicor Replication, one of the replication processes must use startup, but, that is the only exception.
make sure to make use of “task purge frequency” in the system agent (do users really need to reprint reports 30 days after they were originally printed? if not, the purge can be adjusted - that’s new as of 9.05.700).
if you are a SQL backend, rebuilding indexes with the Standard SKU of SQL is an offline operation, so it makes the table inaccessible while the clustered indexes are being built. The background processing aspect of Epicor 9.05 doesn’t handle a table not being there (and, we check every X seconds where X is the number of seconds set on the system agent for processing delay) so a restart of those appservers would be needed after an index rebuild. If you have the Enterprise SKU, you can rebuild indexes online.
When we were on 9.05 our only thing from your list was having some user
submitted items in Startup. But we moved them to a schedule we made and
still had the problem every not-and-again.
Here too, our issues were so bad initially I had a schedule to restart the app servers every night. A little extreme, I admit. I suspect that it may have been related to having hardware that just met the performance requirements. We are now running new servers with NVRAM and performance is much better. That being said I have not had the time to experiment with restarts every second day or longer yet.
As far as replication goes, if you are only using replication for AFR and you are on SQL then I would be using the SQL replication comes with it. How many people use AFR?
Our hardware FAR exceeds the requirements and we still had to do the restarting, and still have performance issues, I might add, even though the resources go unused.
We use AFR. AFR really just sets up a bunch of stuff in SQL and SSRS so those engines do all the work. I question the value of the AFR viewer because I can tell that the AFR viewer is just presenting the SSRS website inside a specially branded box.
E9.702A - Progress 64-bit. No Problems at all - a restart rarely happens unless i am adding UD Fields to run Schema Update. We do run MRP on a Schedule etc… Have Replication running as well + Sonic.
