Centerprise job fails when deployed to a new server

Here is an update on this issue.

Development Environment:

Our developer is reporting that when he deployed the package to our server, the Astera service stops and needs to be manually restarted every day. This is the case even when the startup is set to Automatic.

User Testing Environment:

We installed it on our UAT server, and the installation went fine. When our developer started to schedule jobs though, the server quit and did not start and stay running. Here is the error in the application log.
Object reference is not set to an instance of an object.

at Astera.Scheduler.FileWatcherList.a()
at Astera.Scheduler.Scheduler2.e()
at Astera.Scheduler.Scheduler2.a()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

We are now unable to connect to the server to manage or schedule anything as it will not stay running.

Hi,

To get past this, stop the server and rename the .sdf file found in c:\programdata\astera software\astera integration server. This is where the schedules are kept, but at least you’ll be able to keep moving.

Is this the latest build I gave you to see if it curbed memory consumption?

This build is the other server. This server was having issues with the Access drivers. I believe it is the build you sent for that particular problem, not the memory consumption problem. I searched all files on the server named .sdf and did not find anything. Any more ideas.

It is not going to be in the program files directory. It is going to be in the ProgramData directory.

This file is deployed during the initialization time of the server. If the server runs for any time at all, it gets deployed. The only reason it would not be there is if an error occurred during initialization. But I would think that if this happened, you wouldn’t need to “restart” the service as it would never be able to be started at all.

I’m going to translate this stack trace to see if I can figure out where the error is occurring.

There is not a program data folder on the system. The service was up and running for a while, but when our developer added tasks, it died.

I looked at our 64-bit windows 2008 server and I see the folder there. I do not see the folder on either of the windows 2003 servers we are working on (Dev and UAT) or on our old windows 2003 server.

Ah,

This is a change in windows from Vista on. Previously, this fold could be found on c:\documents and settings\all users\application data.

Thanks. The service now starts.

Any idea about the service on the Development server? It looks like the memory is growing on that one. That could be why it is shutting down. It is currently at 788MB and growing. It is not a 64-bit install (according to the information page from centerprise) but it does not have the *32 after the process name.

This is from our developer who is working on the Access issue.

I’m not sold on this 32-bit version of Astera. When the memory is over 1,000,000K, on the Astera.TrasferService.exe process, I get the following error when running the PAR import process. I then restarted the Astera service and rescheduled the import process. Then it works. I don’t know what Astera can do about the memory consumption issue. This is not an issue on the current LDMT3609 version of Astera (version 4.0.84.8)

(LUWZW6633) 6/6/2012 7:10:01 AM: This is a NON-PRODUCTION server and is not to be used in a production environment.
(LUWZW6633) 6/6/2012 7:10:01 AM: GetandProcess.batch: Execution started
(LUWZW6633) 6/6/2012 7:10:01 AM: Verification \LUWZW6633\E$\WFSC\PAR\Centerprise\Settings\AlltelImport\GetandProcess.batch <file:///\LUWZW6633\E$\WFSC\PAR\Centerprise\Settings\AlltelImport\GetandProcess.batch> : Verification failed. Error accessing database table for verification. ERROR [HY001] [Microsoft][ODBC Microsoft Access Driver] System resource exceeded.

ERROR [IM006] [Microsoft][ODBC Driver Manager] Driver’s SQLSetConnectAttr failed
ERROR [HY001] [Microsoft][ODBC Microsoft Access Driver] System resource exceeded…
(LUWZW6633) 6/6/2012 7:10:01 AM: GetandProcess.batch: Execution ended
(LUWZW6633) 6/6/2012 7:10:01 AM: GetandProcess.batch : Execution terminated due to error. Error accessing database table for verification. ERROR [HY001] [Microsoft][ODBC Microsoft Access Driver] System resource exceeded.
ERROR [IM006] [Microsoft][ODBC Driver Manager] Driver’s SQLSetConnectAttr failed
ERROR [HY001] [Microsoft][ODBC Microsoft Access Driver] System resource exceeded…
(LUWZW6633) 6/6/2012 7:10:01 AM: Error information written to file://\Luwzw6633\wfsc\CenterpriseStaging\fay.yee\Log\GetandProcess.err <file:///\Luwzw6633\wfsc\CenterpriseStaging\fay.yee\Log\GetandProcess.err>

It looks like we have the memory consumption issue on this server also.

Please try the new build that I have emailed. Let me know if the issue gets resolved.