I am getting timeout errors on the following line of code and it does not happen very often, like once in every twenty times it does happen.
19 times the following line doesn't give any error but all of sudden it gives the time out error.
Any help would be appreciated.
CStaffUser Staffuser = CStaffUser.Login(ConfigurationManager.AppSettings["tloginid"].ToString(), ConfigurationManager.AppSettings["tpassword"].ToString());
Thanks,
Sapna
The Publishing service has a feature (called Site Service in the config file) which will keep a website active by accessing a page every few minutes. It is one way of keeping .NET from stopping the app pool unnecessarily. Another way is to set the "Idle Time-out (minutes)" setting to the same value as the recycle interval (which defaults to 1740 minutes), so .NET won't care if it goes idle.
You want to avoid recycling the app pool when it isn't necessary. Under iMIS 15.1.3 and previous, the application startup can be very slow. So far, iMIS 15.2 seems to start up with much less delay. I'm not sure if this is to ASI's credit or because iMIS now uses .NET Framework 4.0 -- probably a little of both.
Note that other things can cause a recycle, too. Editing any config file, or adding or changing files in the /bin/ folder will cause an immediate restart. If the website experiences more than 5 errors in 5 minutes, it will recycle the app pool as well. (The specific limits are configurable -- these are the defaults.)
The recycle at regular intervals is still important, just in case iMIS develops a memory leak. The recycle essentially "reboots" the iMIS application, clearing memory and getting a fresh start. The scheduled recycle is a "just in case" setting chosen by Microsoft to try to keep web applications healthy even when nobody monitors the site for trouble. By letting this recycle happen at regular intervals, it is less likely to happen as part of someone's request, and the time spent starting up is invisible.
--
Bruce Wilson
Director, Technical Services
RSM McGladrey, Inc.
Every so often the IIS app pool freezes. This causes orders not to process when using a PO to place an order.
Previously this was attributed to a failure to send emails because the Baracuda device was blocking the volume of emails from being sent.
Once the Baracuda was removed from the SMTP routing those IIS app pool freezes stopped happening.
Now we are seeing carts that show completed but he orders are not seen in iMIS or the confirmation emails being sent until the App Pools are recycled.
The Staff Browser View and the iMIS Public View each have their own App Pool.
Log Name: System
Source: Microsoft-Windows-WAS
Date: 3/15/2012 11:39:27 PM
Event ID: 5186
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: agc-web.agcstl.local
Description:
A worker process with process id of '4512' serving application pool 'iMISPublic' was shutdown due to inactivity. Application Pool timeout configuration was set to 20 minutes. A new worker process will be started when needed.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-WAS" Guid="{524B5D04-133C-4A62-8362-64E8EDB9CE40}" EventSourceName="WAS" />
<EventID Qualifiers="16384">5186</EventID>
<Version>0</Version>
<Level>4</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2012-03-16T04:39:27.000000000Z" />
<EventRecordID>42458</EventRecordID>
<Correlation />
<Execution ProcessID="0" ThreadID="0" />
<Channel>System</Channel>
<Computer>agc-web.agcstl.local</Computer>
<Security />
</System>
<EventData>
<Data Name="ProcessID">4512</Data>
<Data Name="AppPoolID">iMISPublic</Data>
<Data Name="Minutes">20</Data>
</EventData>
</Event>
Bruce M Walker
BSCI
Chicago IL
Log Name: System
Source: Microsoft-Windows-WAS
Date: 3/21/2012 2:59:01 PM
Event ID: 5152
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: agc-web.agcstl.local
Description:
The application pool 'DefaultAppPool' has an IdleTimeout '1740' equal to or greater than the PeriodicRestart time value of '1740'. This means that the worker process will never idle timeout, since it will restart before the idle timeout is reached. Please confirm that this is the desired behavior and if so, consider disabling the idle timeout by setting it to '0'.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-WAS" Guid="{524B5D04-133C-4A62-8362-64E8EDB9CE40}" EventSourceName="WAS" />
<EventID Qualifiers="32768">5152</EventID>
<Version>0</Version>
<Level>3</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2012-03-21T19:59:01.000000000Z" />
<EventRecordID>43193</EventRecordID>
<Correlation />
<Execution ProcessID="0" ThreadID="0" />
<Channel>System</Channel>
<Computer>agc-web.agcstl.local</Computer>
<Security />
</System>
<EventData>
<Data Name="AppPoolID">DefaultAppPool</Data>
<Data Name="IdleTimeout">1740</Data>
<Data Name="PeriodicRestartTime">1740</Data>
</EventData>
</Event>
Thank You
BMW
Try
{
}
Catch {
312.553.1253 x230
}
Finally
{
Call Robert Bainer 312 553 1253 x 231
}
The IdleTimeout of 20 minutes, and the periodic recycle of 27 hours (1740 minutes) are default values from Microsoft. They are designed to keep a site running reasonably well without supervision, and to allow test sites to drop off the radar when not needed.
ASI's SiteService (configured as part of the Publishing service) polls each iMIS site on a regular basis. This helps with startup, but it also means a site will never be idle long enough for the IdleTimeout to kick in. As a result, I generally just turn off the IdleTimeout by setting it to zero.
The message above isn't an error, just a notation that the settings don't really make sense.
If you need the site to restart periodically, you can turn the recycle time down so it will restart more often on its own, but the shorter you make this timeframe, the harder your server will have to work. A setting of 5 hours (300 minutes) is not too terrible on most servers. Anything below an hour is getting pretty extreme.
Note that if you don't have a static machinekey assigned, all user sessions will be terminated (with an ugly "Viewstate could not be decrypted" error) whenever the app restarts. A static machinekey is highly recommended.
I've had better results splitting all the various iMIS sites into their own app pools. This gives each site its own 4GB memory space, instead of sharing one 32-bit memory space among all sites.
P.S. love the sig.
--
Bruce Wilson
Director, Technical Services
McGladrey & Pullen, LLP
Timeout error occurs when
Timeout error occurs when your iMSI15 membership web services aren’t responding within period of time. Make sure memberships web services are always available when you calling login methods.
I would suggest you to run ASI publishing services to avoid timeout errors on your test/live systems. Which stops IIS to recycle the application pool when the site is not accessed period of time.