function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
PushkarPushkar 

Http call outs from Apex class

Hi,

I implemented a sample Http callout from an apex class to my server. But it always gives me a "System.CalloutException: Read timed out". I could not find any relevant information while searching on salesforce.

1. How do I confirm that my server is reachable from salesforce? (i believe it is that is why it is throwing a Read timed out exception in place of unreachable destination host or host not found).

2. I am using secure http i.e. https protocol. Are there any specific settings required on salesforce for this?

3. It is a servlet that I am trying to contact. I suppose that would work and I do not necessarily need to expose a web service.

Following is the class I am using. I accessing it as a web service.

global class HttpCalloutSample
{
    webService static String getContent(String url)
    {
        Http h = new Http();
        HttpRequest req = new HttpRequest();
        req.setEndpoint(url);
        req.setMethod('GET');
        HttpResponse res = h.send(req);
        return res.getBody();
    }
}


- Pushkar
aslamaslam
Hi,
I am also getting the same error.
CalloutException: Read Time out.

My Code psuducode is like:-
HttpRequest req = new HttpRequest();
    
     req.setEndpoint('http://someweburl.com');
     req.setMethod('POST');
     req.setBody('email_address=abc@domain.com&password=this&detail=yes');

 
     String username = 'abc@domain.com';
     String password = 'this';
 
     Blob headerValue = Blob.valueOf(username+':'+password);
     String authorizationHeader = 'BASIC ' +   EncodingUtil.base64Encode(headerValue);
     req.setHeader('Authorization', authorizationHeader);
  
     // Create a new http object to send the request object
     // A response object is generated as a result of the request 
 
     Http http = new Http();
     try{
         HTTPResponse res = http.send(req);
         errorCode = res.getStatusCode()+' ';
         status = res.getStatus();
         body = res.getBody();
     }catch(Exception e){
         status = e+' ' ;
     }


Any Help Please ASAP
Thanks
Ron HessRon Hess
your service must respond within 10 seconds, this timeout is not configurable
PushkarPushkar

Ron,

The sample server response is short enough to respond within 10 seconds. The thing is I don't see the request reaching my servlet and the code just reponds with a timeout exception.

1. Is there any way from salesforce to determine that the request is reachable?

2. Secondly, assuming that my server is blocked to incoming requests. Is there a list of secure salesforce IPs that I should allow on my server to recieve the incoming requests from without any security risk?

Thanks,

Pushkar



Message Edited by Pushkar on 09-09-2008 11:17 PM
Ron HessRon Hess
you web service must be visible to our servers

here is the detail on our IP addresses

at http://blogs.salesforce.com/successforce/2008/02/new-ip-addresse.html





Message Edited by Ron Hess on 09-10-2008 01:02 PM
paul-lmipaul-lmi
i'm running into the same issue.

we're using a web service called Defensio that's running on a dedicated server for our implementation.  we are seeing frequent "Red Timed Out" errors per hour, and it's not Defensio's fault.  the servers are indeed responsive, and the typically response time is under 2 seconds, let alone your max of 10 seconds.

this got worse with the Winter '09 rollout, so I'm thinking this may be a scalability issue on your end, as far as the servers inside SFDC that are servicing the callouts.

i had implemented a retry as part of a try..catch clause in my code, but even this is failing now, so i'm really concerned here.

normally this works extremely well for us, but spotty service is making me want to reconsider using the salesforce apex platform for this functionality in lieu of our own hardware.
PushkarPushkar

I built a bridge to allow interaction between the apex controller of a visualforce page and a local application server.

---- Visual force page ----

Code:
<apex:page controller="myPageController">
  <apex:form id="f">
    <apex:actionFunction id="af" name="myAction" action="{!myAction}" rerender="out" status="myStatus">
      <apex:param id="xyzIds" name="xyz_ids" assignTo="{!myXyzIds}" value=""/>
    </apex:actionFunction>
  </apex:form>
  <apex:outputPanel id="out">
    <apex:outputText value="{!contactIds}"/>
    <apex:actionStatus startText="Loading..." id="myStatus">
    </apex:actionStatus>
  </apex:outputPanel>
  <script language="javascript" src="https://myhost.com:8444/get-xyz—objId={!$CurrentPage.Parameters.objId}"/>
</apex:page>
 
--- Controller ---
Code:
public class myPageController {

    String myXyzIds = 'initial value.';

    public String getXyzIds() {
        return contactIds;
    }

    public void setXyzIds(String c) {
        contactIds = c;
    }

    public PageReference myAction() {
    /** process the results obtained from the app server here **/
        return null;
    }
}
  The script that is loaded here invokes the action function with parameters obtained from the application server. This way I am able to transfer some data to the controller.

Thanks,
Pushkar



Message Edited by Pushkar on 10-07-2008 11:13 PM

Message Edited by Pushkar on 10-07-2008 11:14 PM
paul-lmipaul-lmi
i'm pretty sure this functionality is just crippled since the winter '09 release.  I opened a ticket over 10 days aog with support and haven't gotten a response, meanwhile, at least 10% of my http callouts are timing out, and that's even including the fact that part of the try...catch statement around the callout has the catch statement retrying the same thing.

this was perfectly for months, and now it's making me rethink complete business processes, which i'm pretty frustrated about.

even more annoying is the feeling that even after waiting over 10 days for a support response, i'll still get some BS canned message that has no relevance to http callouts at all, or even better, some statement about not getting support because we don't pay for "premium" support.

i love the salesforce platform, but when things go wrong, everyone has to fend for themselves it seems.
cheenathcheenath
The endpoint you are trying to access is public? If so I could try it out see how long it is taking.

 

cheenathcheenath
I just tested http://cheenath.com from na3. My requests are taking few ms to complete.


paul-lmipaul-lmi
yes it's internet accessible, however, it's not just some URL you can point to.  It requires a POST, not a GET.  All my manual tests show that even the most intensive API calls are replied to in under 5 seconds.
paul-lmipaul-lmi
how are you determining length of request in apex?
paul-lmipaul-lmi
also, we're on NA1.  this literally started being an issue the day after NA1 was updated to Winter 09.  Before that, requests failed here and there, now, hundreds per day fail.
cheenathcheenath
I ran it in system log, it prints the timestamp for each System.debug.

It could be something to do with the network. Your tests are fine since you are
running it inside your lan?

 
paul-lmipaul-lmi
if it was the network, it would be the Salesforce network.

The API calls are being sent to machines running on Amazon AWS, so my location shouldn't matter.
paul-lmipaul-lmi
i just ran 5 tests, and right now, the entire callout takes less then 1 second from start to finish.  i'm sure this varies with the load on teh salesforce side, but what i can say is i'm pretty confident it's not on the amazon side.

any other ideas?
paul-lmipaul-lmi
i think they are throttling requests per minute or something.  they don't mention it in the documentation, but that's the only thing i can think of.  we process about 2000 of these requests that require a callout per day.

can anyone confirm a hard cap on number of requests per minute?
cheenathcheenath

There isnt any major change to callout in winter 09. So I dont suspect any code change.
Load can be an issue. Is there any pattern for the callout failure? Like time of day, day of
the week etc? If there is, i can look through the logs at that time.


paul-lmipaul-lmi
i'll start tracking by date/time for 24 hours and let you know.  i doubt it though.
cheenathcheenath
There is no requests per minute throttling on sfdc. what about amazon?
Are you making the calls in parallel or one after the another? There are limits
on how many concurrent call can be made to a given endpoint (i think the limit
is 10). But you should get a different error message if you are hitting this limit though.





paul-lmipaul-lmi
definitely not hitting a concurrency limit.  the servers i'm hitting are hosted on amazon, but not limited by amazon.  there are no concurrency limits there either, and this specific server is dedicated to us.
paul-lmipaul-lmi
is it 10 concurrent requests per domain globally, or just in our org?  is that based on domain name, or IP address?
cheenathcheenath
-Not domain, for each server name (ip address if you are using ip address to access endpoint).
- It is per sfdc server, not per org.
It is hard to hit this limit, unless you are doing a lot of concurrent callouts.

-
paul-lmipaul-lmi
ok

the server name i'm hitting is test-salesforce.defensio.com if you're interested.  it won't respond to anything but api calls though.
paul-lmipaul-lmi
here are the stats since yesterday.

First column is hour, second column is number of request timeouts.  Double the second column, since my catch logic is an immediate retry of the request.  Times are in SF default times that the data loader uses, as that's what I exported this info with.  If that is UTC, then that's what these are, if it's my time zone, than these are in EDT.

Hour                         failures
004
011
024
031
045
055
063
075
082
095
104
117
124
133
144
1520
163
177
185
222
234

Total 98 failures.  Every failure results in manual work of some sort, so this is killing productivity for the person doint it now.
cheenathcheenath
I could only find 20 failed calls among many thousands of calls to amazon
yesterday from na1. All going to https://s3.amazonaws.com/soap

Is this the endpoint you are trying to reach? Going through the logs I couldnt
find anything specific.


paul-lmipaul-lmi
no, it's test-salesforce.defensio.com

(it's hosted on amazon ec2)
cheenathcheenath
I see it now. It seems most of your calls are done in 4 sec or less. But few calls are
taking more than 10 sec. I couldnt get any clue on why it should be doing that.
Anyway, we are working to relax this limit and this should be a non issue in another
few months. I am not sure what you could do in short term, though.

 
vikiviki

I don know how old this topic is, but the timeout is configurable.

Link : http://www.salesforce.com/us/developer/docs/apexcode/index_Left.htm#StartTopic=Content/apex_web_services_wsdl2apex.htm#callout_timeouts

 

For Http rest service :

    HttpRequest req = new HttpRequest();

    req.setTimeout(2000); //timeout in milliseconds

 

Thank you

CQLCQL

I know this is an old thread, but I hit this problem as well recently.  It is noteable that this thread started in 2009, because that is when a particular type of "man-in-the-middle" attack was identified with SSL and TLS message constructs.  If your external endpoint is an https endpoint, then the destination firewall or IDS system may be blocking it.  I found that some of my posts from Apex to an external endpoint were working ok, but some, particularly POSTs with request body content would not.  Interesting POST messages without a request body worked ok, but not if there was a body on the request.  I was getting "read timed out" no matter what timeout I gave it.  I found the destination firewall was blocking it due to an intrusion detection rule concerning CVE-2009-3555.  Interestingly, posts from java applications built with java 6 or java 7 to the exact same endpoint had no problem with this, only the Apex posts.  I had to create an exception rule in the destination firewall to allow traffic from the SalesForce IPs to ignore this IDS rule.  After that exception was put into the firewall, never saw the "Read Timed Out:" again.