We are using KingswaySoft SSIS integration to push data (60k) into CRM 2015. There is a daily job which is set to run this package, which passes successfully sometime and fails sometime with this error. Please suggest troubleshooting/fix.
Delete Sales Transaction data of months in CRM:Error: An error occurred with the following error message:
KingswaySoft.IntegrationToolkit.DynamicsCrm.CrmServiceException: CRM service call returned an error: CRM service call returned an error: The request channel timed out while waiting for a reply after 00:02:59.9843634. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.(Error Type / Reason: Timeout) (SSIS Integration Toolkit for Microsoft Dynamics CRM, v7.0.0.5660 - ISServerExec, v11.0.5058.0)
KingswaySoft.IntegrationToolkit.DynamicsCrm.CrmServiceException: CRM service call returned an error: The request channel timed out while waiting for a reply after 00:02:59.9843634. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.(Error Type / Reason: Timeout)
System.TimeoutException: The request channel timed out while waiting for a reply after 00:02:59.9843634. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.
System.TimeoutException: The HTTP request to 'crm.abc.com.au/.../Organization.svc' has exceeded the allotted timeout of 00:03:00. The time allotted to this operation may have been a portion of a longer timeout.
System.Net.WebException(Status Reason: Timeout): The operation has timed out
Also since it is giving timeout issue, is it worth trying to increase timeout period? please guide how we can perform it.
First of all, we thank you for choosing KingswaySoft.
For the timeout error that you are getting, it indicates that a service call is taking a longer time than what you have specified in the connection manager. There are a couple of options in your case.
If this is happening to a CRM destination component, you should
consider decreasing its Batch Size setting.
If you are using Upsert action with manually specified key fields in the destination component, you want to make sure you have created db indexes for the fields that you have selected for Upsert matching.
You may also increase your CRM connection manager’s Timeout setting.
Based on the error message, it appears that you are using 180 seconds as your timeout setting, which is plenty for any service calls. Having a timeout error in this case could be an indication that you have some design issues with your CRM application. You might want to revisit your CRM plugin or workflow code if you have any.
Related
Each morning at 4am a Scheduled Task creates around 500 messages on a message queue. Each message is an id of an email to send. Each message is picked up and a url created and sent via await HttpClient.GetAsync(url) The url target then creates and sends the email. This has worked well for months.
I've just upgraded to SQL Azure v12 and all is now not well.
The very first messages to be processed (after 2 minutes running time) threw a
"System.Threading.Tasks.TaskCanceledException"
I'm also seeing
"System.Data.Entity.Core.EntityException: The underlying provider
failed on Open. ---> System.InvalidOperationException: Timeout
expired. The timeout period elapsed prior to obtaining a connection
from the pool. This may have occurred because all pooled connections
were in use and max pool size was reached."
and a couple of
"The timeout period elapsed prior to completion of the operation or
the server is not responding. This failure occurred while attempting
to connect to the routing destination. The duration spent while
attempting to connect to the original server was - [Pre-Login]
initialization=6; handshake=426; [Login] initialization=0;
authentication=0;"
The webjob that sends the request to the api is awaiting a response. I'm wondering if because it's async, while awaiting the response the thread is freed to go off and processes another queue item - and therefore creates another api request, essentially this hits the api again and again until there are so many requests being processed by the api all the theads are in use - and that I might be better off NOT making the webjob async because then it (the 'trapped' thread) would send a request only after the first request completes? Is that right? edit: actually the IIS logs suggest that the api requests are not all happening at once. So my question is "what should I look at next? Are these common SQL v12 errors or is the recent upgrade a red-herring?"
just to clarify, the webjob that fires in response to the queue message simply does:
using (HttpClient client = new HttpClient())
{
response = await client.GetAsync(url);
}
and hits the web api of an Always On standard tier azure website. Database DTU % is about 25% while this happens.
edit:
"Gateway no longer provides retry logic in V12 Before version V12,
Azure SQL Database had a gateway that acted as a proxy to buffer all
interactions between the database and your client program. The gateway
provided automated retry logic for some transient errors.
V12 eliminated the gateway. Now your program must more fully handle
transient errors."
adding DbConfiguration class for SqlAzureExecutionStrategy. Will so how it runs tonight.
Adding the EF retry config class fixed the transient errors. The cancelled tasks are a different issue (new question)
//https://msdn.microsoft.com/en-us/data/jj680699
public class SqlAzureConfiguration : DbConfiguration
{
public SqlAzureConfiguration()
{
this.SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy());
}
}
and in web.config (because I have multiple contexts)
<entityFramework codeConfigurationType="Abc.DataService.SqlAzureConfiguration, Abc.DataService">
getting this error message in the wcf client log
The HTTP request to
'http://blah.svc'
has exceeded the allotted timeout of 00:15:00. The time allotted to
this operation may have been a portion of a longer timeout.
followed by
The request channel timed out while waiting for a reply after
00:14:59.9979998. Increase the timeout value passed to the call to
Request or increase the SendTimeout value on the Binding. The time
allotted to this operation may have been a portion of a longer
timeout.
However the service call had been made less than a minute before this. Any ideas as to what could cause this misreported timeout?
It happens for more than one machine so I don't think it is http://www.andyfrench.info/2010/11/wcf-service-throwing-immediate-timeout.html
Setting the following timeouts
OpenTimeout, CloseTimeout = 30 seconds
ReceiveTimeout, SendTimeout = 15 minutes
Our server log shows the request as being successful. Before and after this there have been fully successful service calls. Its not a single particular method on the service either.
I get this error.
The request channel timed out while waiting for a reply after 00:01:00. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.
I am using an automcompleteextender which calls a [webmethod] which in turn calls a WCF service. The problem is when i enter 3 letters at a time the service call freezes. The extender never works. No other autocompleteextender works on the page later.
I have already tried setting sendTimeout and maxReceivedMessageSize. It doesnt help.
Please provide a word around.
Well i solved the issue. It was really strange on how it got solved.
I had to change the binding from WsHttpBinding to BasicHttpBinding
Everything else remained the same. It was just the Binding
I am trying to achieve the following - one client-side proxy instance (kept open) accessed by multiple threads using a reliable session. What I have managed so far is to have either A) a reliable session with a client-side proxy which is created and disposed per call or B) what I aim for, but without a reliable session.
When I enable reliable sessions on my binding however, the following behaviour is exhibited:
Client-side
Upon application startup everything appears to work fine until roughly 18 messages in to the WCF session. I firstly get the proxy.InnerChannel.Faulted event raised, then an exception is caught at the point where I am calling the method on the proxy. The exception is a System.TimeoutException, with message:
"The request channel timed out while waiting for a reply after
00:00:59.9062512. Increase the timeout value passed to the call to
Request or increase the SendTimeout value on the Binding. The time
allotted to this operation may have been a portion of a longer
timeout."
The inner exception has a similar message:
"The request operation did not complete within the allotted timeout of
00:01:00. The time allotted to this operation may have been a portion
of a longer timeout."
With the method at the top of the inner stack trace being:
System.ServiceModel.Channels.ReliableRequestSessionChannel.SyncRequest.WaitForReply(TimeSpan timeout)
I then call proxy.Close followed by proxy.Abort (catching and ignoring exceptions). If I utilize the default settings (i.e. have simply <reliableSession/>), then calling proxy. Close results in another System.Timeout exception (although this time the allotted timeout is 00:00:00), however if I override the defaults as specified above no exception is thrown.
Service-side
Utilizing WCF tracing I get a System.ServiceModel.CommunicationException, with message:
"The sequence has been terminated by the remote endpoint. The session
has stopped waiting for a particular reply. Because of this the
reliable session cannot continue. The reliable session was faulted."
And a stack trace ending at:
System.ServiceModel.AsyncResult.End[TAsyncResult](IAsyncResult result)
When remotely attaching to the server I get the same message, which occurs when code execution steps over the return statement of my service in the service call which causes the error.
The puzzling thing to me is that the service is stable and runs with options A) or B) as decribed at the beginning of my post, and occurs after a varying number of messages (around 18). The former fact points to there being nothing wrong with the code (indeed I have checked that no exceptions are thrown), and the latter just serves to confuse me and is why I modified the settings on the reliable session binding.
I am quite stuck on this. Can anyone suggest why the reliable session would fault in such a way?
You need to overide the default ,and set your timeout higher or lower depends on cause,it seems the timout is causing an exception just after some other program has started or stopped just a millisecond before the exception
OR most likely cause
your alloted timeouts may be added as a continous single timeout of 18 min or 18 calls ..plus other usage times are added together as one complete time out .which may be why it asking for more time.
in any case ,you have to staticly set your own settings because automatic default will always over ride any changes you made..
type in your local host http binding name and set your closetimeout at maybe 5.00 min
and maybe even change the request time as well . Requesttimeout 2.00 min
closeTimeout="00:05:00"
When I invoke a remote WCF service I get the following timeout:
The request channel timed out while waiting for a reply after 00:00:59.2810338. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.
Please note that I am sending a single object which is LOADED with a LOT of data.
Any ideas how to fix this issue and is this a problem on the client (ME) or the Server.
Given the size, have you tried increasing your maxBufferSize/maxReceivedMessageSize in your binding?
Chunk your data into smaller pieces if possible and try again. This is a server setting that you will need to work around or request that the service provider increase it.
Without a stack trace I'm can't be 100% sure, but I'm relatively certain this is a client side exception. If you know it's going to take more than a minute to send the data all you need to do is change the sendTimeout on your binding to be whatever amount of time you need it to be.