Hi,

As per your above post what I can understand is that, to download the Emails in CRM you restart the Tomcat Service each and every day. As per my knowledge CRM E-mail Manager Service is used to download the emails against configured email accounts in CRM. To avoid restart of the service you can try below given steps.

1) Go to Start || RUN

2) Enter Services.msc and click Ok button

3) Select CRM E-mail Manager

4) Right click on service and select Properties option from list

5) Go to Log On Tab

6) Select This Account radio button

7) Enter you Admin User login details and click Ok button

8) Restart the same service again and Check the same

Hope this helps!

Regards,

Dinesh

Yes,

Seems like Sage are aware of it too: -

community.sagecrm.com/.../how-to-schedule-a-tomcat-service-restart.aspx

Thanks guys! David Gelula from Azamba gave me a solution that works for me: Allocate more RAM to Tomcat in the registry.

(64 bit machine)

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\CRMTomcat6\Parameters\Java

or

(32 bit machine)

HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 2.0\CRMTomcat6\Parameters\Java

Double click the Options value and add the line: -XX:MaxPermSize=256m

Hi guys,

Just to go into a little bit more detail here (it's interesting!). You shouldn't have to restart the Tomcat service regularly if you're using the Exchange integration. If a webapp is crashing out, you'll want to find out the reason why this is happening.

The solution given above (from David Gelula in Azamba) works very well, but it's for a specific issue - basically if the PermGen memory allocation is set too low, and a webapp attempts to use too much memory, it will crash out. It can't be increased dynamically, as the memory allocation has to be done when the JVM kicks off. This will cause an error similar to the following in the Tomcat service logs (..\CRM\tomcat\logs\):

SEVEServlet.service() for servlet dispatch threw exception
java.lang.OutOfMemoryError: PermGen space

If you don't see anything else going on in the service logs, then increasing the PermGen allocation will resolve the issue. By default, this is set to 256MB from v7.1h onwards, and 512MB in v7.2. The v7.2 installer can reduce this downwards if it finds it can't start the Tomcat service, say if you're trying to install CRM on a laptop. It will try 512MB first, then 256MB, then finally 128MB. Since you'll need this amount of memory free in RAM for the Tomcat to start, it worth making sure you've any memory hogs (Outlook, Powerpoint, loads of Chrome tabs) closed down when doing a CRM install on a personal machine.

Other issues can cause memory leak-like behaviour that will result in a PermGen error. Setting the allocation higher in these instances will not resolve the issue. Here's a doozie:

Exchangesyncenginestacktrace.log:

2012-01-17/17:44:07.112/GMT+10:00 [SyncEngine thread] ERROR com.sage.scrm.syncengine.exchange.engine.SynchronisationThread.run com.sage.scrm.syncengine.core.engine.error.SageSyncEngineException: com.sage.scrm.syncengine.exchange.engine.model.error.SageSDataEndpointException: com.sage.scrm.core.httpconsumer.error.SageHttpConsumerException: POST on CRMSERVER/.../$syncTarget failed: 500
com.sage.scrm.syncengine.core.engine.error.SageSyncEngineException: com.sage.scrm.syncengine.exchange.engine.model.error.SageSDataEndpointException: com.sage.scrm.core.httpconsumer.error.SageHttpConsumerException: POST on http://CRMSERVER/sdata/crmj/crmExchange/-/appointments/$syncTarget?trackingId=8cc28e3f-66c5-44f3-a6c8-1151000de40f failed: 500
at com.sage.scrm.syncengine.exchange.engine.SynchronisationProcess.execute(SynchronisationProcess.java:202)
at com.sage.scrm.syncengine.exchange.engine.SynchronisationThread.synchroniseResourceOneWay(SynchronisationThread.java:296)
at com.sage.scrm.syncengine.exchange.engine.SynchronisationThread.synchroniseResourcesOneWay(SynchronisationThread.java:285)
at com.sage.scrm.syncengine.exchange.engine.SynchronisationThread.run(SynchronisationThread.java:173)
at java.lang.Thread.run(Unknown Source)

This indicates an error 500 when the synch engine is doing a POST to the CRMJ webapp (this is how it gets data in and out of CRM). Since we're getting an error 500, we can figure that the CRMJ webapp has junked out, and is therefore unable to write an error to the main CRM logs. The actual error will be handled and logged by the Tomcat service.

Here's what you'll see in Tomcat's localhost.log:

17/01/2012 5:44:07 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVEServlet.service() for servlet dispatch threw exception
java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at org.mozilla.javascript.DefiningClassLoader.defineClass(DefiningClassLoader.java:62)
at org.mozilla.javascript.optimizer.Codegen.defineClass(Codegen.java:147)
at org.mozilla.javascript.optimizer.Codegen.createScriptObject(Codegen.java:102)
at org.mozilla.javascript.Context.compileImpl(Context.java:2293)
at org.mozilla.javascript.Context.compileString(Context.java:1240)
at org.mozilla.javascript.Context.compileString(Context.java:1229)
at org.mozilla.javascript.Context.evaluateString(Context.java:1085)
at com.sage.scrm.model.util.JavaScriptRunnerCRM.runScript(JavaScriptRunnerCRM.java:245)
at com.sage.scrm.model.util.JavaScriptRunnerCRM.runScriptFunction(JavaScriptRunnerCRM.java:212)
at com.sage.scrm.model.util.JavaScriptRunnerCRM.runScriptFunction(JavaScriptRunnerCRM.java:207)
at com.sage.scrm.model.util.TableLevelScript.execute(TableLevelScript.java:57)
at com.sage.scrm.model.db.WriteQuery.executeTableLevelScript(WriteQuery.java:317)
at com.sage.scrm.model.db.InsertQuery.execute(InsertQuery.java:129)

Superficially, this is a similar error to the first one, but looking at the error message we can see that it's being caused when we try to run a table level script. Since we're running the Exchange integration, we can make an assumption that the table level script is on an entity that's synched by the integration. In this case, the buggy script was on the Comm_Link entity. What was actually happening in this case was that a thread was crashing out due to the table script issue, but the memory allocated to it wasn't being cleared by the GC, which caused the PermGen allocation to fill up. Fixing the script resolved the issue.

Anyway, just to sum up: the solution given above is the most likely solution to this, but it's good to be aware of where you should be looking if you need to confirm that this is what's going on.

Hope this helps,
Rob