Test always running behavior in Jitterbit App Builder
Overview
This setting can be a little tricky to test. The App Builder Scheduler runs within the IIS process. The problem is that to release memory IIS recycles its application pools each day by default. Once an application pool is recycled, by default, IIS waits for the first user to login to App Builder, then starts the application pool.
This means that the default behavior of IIS will stop the App Builder application, and the scheduler will stop running until next user logs into IIS.
As an extreme example, assume there is an event scheduled to run on Sunday at 2 A.M. IIS recycles the App Builder application Saturday at midnight, and nobody logs into App Builder until Monday morning. In this example, the scheduler would be offline until Monday morning when the first user logs in, starting the application and defeating the purpose of having an event scheduled for Sunday at 2 A.M.
To manually test whether the 'Always Running' is working, there are a couple options, but both techniques require asking users not to use App Builder during the test. If a user logs into App Builder while testing this feature, it invalidates the test because IIS loads the application pool when the user accesses App Builder.
Check the Windows event logs
When IIS recycles the application pool, a log entry is added to the windows event log with a source of WAS. To find the log entry, open up the Windows Event Viewer on the web server.
-
Locate the system entries:
-
Find an event with Source of WAS and entry similar to:
-
Check the details to see if the event is the App Builder Application pool being recycled. If so, then this event represents IIS recycling the App Builder application pool:
-
Check the date and time of the event. The goal of the Always Running setting is that immediately after the application pool is recycled, the App Builder application should start itself. To determine this, locate your App Builder logs and find log entries that match the date and time of this recycle event. The logs are in the App Builder installation folder under App_Data:
Notice, that at 9:52:42 AM the Application Pool recycled. Then notice in the App Builder log that at 9:52:45 (within 3 seconds), the App Builder Application has restarted. This indicates that the Always Running setting is working for your environment. The application did not wait until somebody logged into App Builder, it started immediately after the application pool was recycled. Again, this test assumes nobody is currently using App Builder. If you want to confirm that no users accessed App Builder at this time, forcing the application to start, check the IIS logs, default folder:
C:\inetpub\logs\logfiles\w3scv1\
Confirm there are no requests that correspond to the time and date that the application started.
Manually confirm the setting
Again, this needs to performed when nobody is using App Builder or the test will be invalid.
-
Stop IIS. From an administrative command line, enter: iisreset /stop
-
Wait a minute prior to starting it back up again. Then enter:
iisreset /start
Once started, check the App Builder application logs in the App Builder installation directory under App_Data. There should be a log entry indicating that the application started immediately after you started IIS.
Note
This could take longer if using the Windows Scheduled Task to ping App Builder)
Check the date and time to confirm that is accurate (immediately after the time you started IIS). Again, this test is not valid if a user is accessing App Builder their requests will also immediately start the application pool.
By default IIS is set to restart every 29 hours (so that the Application Pool is restarting at different times every day). You should configure a specific time of day when the Application Pool restarts, and be sure that this time does not interfere with scheduled background jobs.:
At this point you can choose a time that you know users will not be accessing the system. You can then check the Event Logs to confirm that the application pool recycled at the specified time (steps included in the first option), and you can check the App Builder application logs to confirm that the App Builder application immediately started after the application pool recycled.
If the application is automatically starting after the application pool has recycled, then the scheduler will always be running.
Troubleshooting
If testing is not successful, the following section contains some common issues that have been encountered while implementing the auto start behavior.
Application Initialization is now configured correctly. Following are links indicating how to test the behavior or trouble shoot some common issues that have been encountered.