Hi

You didn't describe what're you doing clearly so it's hard to imagine why.

Did you provide "idle" param in your request? If yes then what value did you pass? This value is time that server waits an incoming message in seconds.

Did you specify a timeout when making the request to Yahoo API server? If yes then please double check what value it is.

Good luck to you!

Hi

I've noticed this same problem happening again since 18:00 GMT yesterday and it's happening at the moment

Let me try and explain more clearly -

I have a windows service which creates a comet style get request to listen for messages from yahoo buddies. It sits there until the default 2 minutes is over and if no messages have been sent and then I raise another comet style get request, as advised in the yahoo documentation.

I have not needed to set the idle parameter. I simply wait for the default timeout to occur and when this happens and I create a new comet style get request.

I have set the timeout for the request to the yahoo api server to be 130 seconds, so that I give the yahoo server a chance to wait in idle state for 120 seconds or 2 minutes.

Now the same problem is ocurring as before. when I raise a comet style get request, I am getting back responses
like "Unable to connect to the remote server" or "The underlying connection was closed, Unexpected error occurred on a receive". These
responses seem to be coming back every 20 seconds.

The solution does work most of the time for many days without problems, but there have been sustained periods where I see
this behaviour and it's happening now.

If you need more information please let me know. Any ideas?

An example of the requests and responses for the above post. I am continually getting 502's and 504's, but something I manage to actually get a successful receive as well of a message.

GET http://rproxy2.messenger.yahooapis.com/v1/...amp;format=json HTTP/1.1
Content-Type: application/json;charset=utf-8
Host: rproxy2.messenger.yahooapis.com
Cookie: IM=2OHUbj2XIWtIeU5rMzIKuSlvkJR7igjEliv30Bxu1hwMAquNbNi5SDILW6jRymtDF0ly5hxKdQvsE
YmY-|WSAdi_SPMeQjdGidSWJkOQ--
Connection: Close

HTTP/1.1 504 Fiddler - Receive Failure
Content-Type: text/html
Connection: close
Timestamp: 15:53:23.781

ReadResponse() failed: The server did not return a response for this request.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

GET http://rproxy2.messenger.yahooapis.com/v1/...amp;format=json HTTP/1.1
Content-Type: application/json;charset=utf-8
Host: rproxy2.messenger.yahooapis.com
Cookie: IM=2ffkuANzIWtJht8asxodx2JllpR7j_e7GC.133bVofjzSSwdUMzxC4x8L4fnuC3sly8HBeQ.5c5OY
qQ--|gktbxngZjiYlzKYfGEISwQ--
Proxy-Connection: Close

HTTP/1.1 502 Fiddler - Connection Failed
Content-Type: text/html
Connection: close
Timestamp: 16:05:06.535

[Fiddler] Connection to rproxy2.messenger.yahooapis.com failed.<BR>Exception Text: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 67.195.186.237:80

Is anybody ever going to reply to this thread.

What is the support model for this SDK, are there any SLAs. Are we able to enter into an agreement with Yahoo, where we can get access to certain support levels?

Can somebody from yahoo please reply to this thread as soon as possible, and the questions in this post?

There was some capacity issue of VIP/LB before which might result in connection failure to Notification server. Please see if you have the same issue. You can also try port 5050 if port 80 has issues.

What is VIP/LB, could you give a little more detail about this? Also are you saying the issue is fixed, has more capacity been added? Is this related to the load on the notification server? I don't think using port 5050 will be an option for us.
Any information including dates when the capacity issue was fixed, will be greatly appreciated?

The capacity issue was fixed about 2 weeks back. VIP/LB is a hardware load balancer sits before the real commet server. The issue we found is not on notification server, it is purely capacity configuration at load balancer.