Since the URL in question is returned from getGzipReportDownloadUrl(),
I am pretty confident that the problem is not on my end. When the URL
is returned from getGzipReportDownloadUrl() is the report file
actually available for downloading or is there some small window of
time before the report is actually copied to the download location??
I have seen this error once or twice before but this is over a course
of a year and thousands of reports. I am wondering if any other
developers have seen this.
> Since the URL in question is returned from getGzipReportDownloadUrl(),
> I am pretty confident that the problem is not on my end. When the URL
> is returned from getGzipReportDownloadUrl() is the report file
> actually available for downloading or is there some small window of
> time before the report is actually copied to the download location??
> I have seen this error once or twice before but this is over a course
> of a year and thousands of reports. I am wondering if any other
> developers have seen this.
Like I said I have seen it two or three times over the course of a
year and we pull thousands of reports in our application. This is not
a huge deal but I was just wondering if there was a theoretical race
condition.
> > Since the URL in question is returned from getGzipReportDownloadUrl(),
> > I am pretty confident that the problem is not on my end. When the URL
> > is returned from getGzipReportDownloadUrl() is the report file
> > actually available for downloading or is there some small window of
> > time before the report is actually copied to the download location??
> > I have seen this error once or twice before but this is over a course
> > of a year and thousands of reports. I am wondering if any other
> > developers have seen this.
I'm actually seeing this issue quite a bit - I've just been asked to
look into it because of the high number of 'URL not found' issues.
What could be causing this? Too many concurrent connections /
reports / logins / something?
As noted above, the URL we're getting is coming straight from
getGzipReportDownloadUrl, and we're hitting the URL immediately after
receiving it. We're also trying it six times before giving up, so if
it were a timing issue, you'd think we'd pick it up in one of the
later attempts.
Can anyone shed any light on this issue? I have report IDs if these
help track down the issue. One such one is 546548514.
I confirm, we are having this issue in the past several days a lot.
Happens sporadically.
In the part of the trace, you can see we re-try getting a different
download url several times.
===============(not found trace + soap log)=======================
=====not fount==================
Utilities.Stabilizers.Armor.SafeExec
areParamsValid == true
Max Try is 4
System.Net.WebException: The remote server returned an error: (404)
Not Found.
at System.Net.HttpWebRequest.GetResponse()
at System.Xml.XmlDownloadManager.GetNonFileStream(Uri uri,
ICredentials credentials)
at System.Xml.XmlDownloadManager.GetStream(Uri uri, ICredentials
credentials)
at System.Xml.XmlUrlResolver.GetEntity(Uri absoluteUri, String
role, Type ofObjectToReturn)
at System.Xml.XmlReader.Create(String inputUri, XmlReaderSettings
settings, XmlParserContext inputContext)
at System.Xml.XmlReader.Create(String inputUri, XmlReaderSettings
settings)
at Utilities.XMLHelper.ValidateXML(DataSet& ds)
at
AdCoreModel.API.AdWordsAPI.ReportsDataService.<>c__DisplayClass6.<SaveRepor t>b__3()
in C:\Inetpub\wwwroot\webServices\AdCoreModel\API\AdWordsAPI
\ReportsDataService.cs:line 399
at Utilities.Stabilizers.Armor.SafeExec(UInt32 maxTries, Type[]
exceptionTypes, CommonWrapper method, UInt32 sleepTime, String[]
detail_InnerText, CommonWrapper backupMethod, Nullable`1 jobRunID)
Going for next try
26/09/2008 01:51:54
Max Try is 3
System.Net.WebException: The remote server returned an error: (404)
Not Found.
at System.Net.HttpWebRequest.GetResponse()
at System.Xml.XmlDownloadManager.GetNonFileStream(Uri uri,
ICredentials credentials)
at System.Xml.XmlDownloadManager.GetStream(Uri uri, ICredentials
credentials)
at System.Xml.XmlUrlResolver.GetEntity(Uri absoluteUri, String
role, Type ofObjectToReturn)
at System.Xml.XmlReader.Create(String inputUri, XmlReaderSettings
settings, XmlParserContext inputContext)
at System.Xml.XmlReader.Create(String inputUri, XmlReaderSettings
settings)
at Utilities.XMLHelper.ValidateXML(DataSet& ds)
at
AdCoreModel.API.AdWordsAPI.ReportsDataService.<>c__DisplayClass6.<SaveRepor t>b__3()
in C:\Inetpub\wwwroot\webServices\AdCoreModel\API\AdWordsAPI
\ReportsDataService.cs:line 399
at Utilities.Stabilizers.Armor.SafeExec(UInt32 maxTries, Type[]
exceptionTypes, CommonWrapper method, UInt32 sleepTime, String[]
detail_InnerText, CommonWrapper backupMethod, Nullable`1 jobRunID)
Going for next try
26/09/2008 01:51:58
Max Try is 2
System.Net.WebException: The remote server returned an error: (404)
Not Found.
at System.Net.HttpWebRequest.GetResponse()
at System.Xml.XmlDownloadManager.GetNonFileStream(Uri uri,
ICredentials credentials)
at System.Xml.XmlDownloadManager.GetStream(Uri uri, ICredentials
credentials)
at System.Xml.XmlUrlResolver.GetEntity(Uri absoluteUri, String
role, Type ofObjectToReturn)
at System.Xml.XmlReader.Create(String inputUri, XmlReaderSettings
settings, XmlParserContext inputContext)
at System.Xml.XmlReader.Create(String inputUri, XmlReaderSettings
settings)
at Utilities.XMLHelper.ValidateXML(DataSet& ds)
at
AdCoreModel.API.AdWordsAPI.ReportsDataService.<>c__DisplayClass6.<SaveRepor t>b__3()
in C:\Inetpub\wwwroot\webServices\AdCoreModel\API\AdWordsAPI
\ReportsDataService.cs:line 399
at Utilities.Stabilizers.Armor.SafeExec(UInt32 maxTries, Type[]
exceptionTypes, CommonWrapper method, UInt32 sleepTime, String[]
detail_InnerText, CommonWrapper backupMethod, Nullable`1 jobRunID)
Going for next try
26/09/2008 01:52:02
Max Try is 1
System.Net.WebException: The remote server returned an error: (404)
Not Found.
at System.Net.HttpWebRequest.GetResponse()
at System.Xml.XmlDownloadManager.GetNonFileStream(Uri uri,
ICredentials credentials)
at System.Xml.XmlDownloadManager.GetStream(Uri uri, ICredentials
credentials)
at System.Xml.XmlUrlResolver.GetEntity(Uri absoluteUri, String
role, Type ofObjectToReturn)
at System.Xml.XmlReader.Create(String inputUri, XmlReaderSettings
settings, XmlParserContext inputContext)
at System.Xml.XmlReader.Create(String inputUri, XmlReaderSettings
settings)
at Utilities.XMLHelper.ValidateXML(DataSet& ds)
at
AdCoreModel.API.AdWordsAPI.ReportsDataService.<>c__DisplayClass6.<SaveRepor t>b__3()
in C:\Inetpub\wwwroot\webServices\AdCoreModel\API\AdWordsAPI
\ReportsDataService.cs:line 399
at Utilities.Stabilizers.Armor.SafeExec(UInt32 maxTries, Type[]
exceptionTypes, CommonWrapper method, UInt32 sleepTime, String[]
detail_InnerText, CommonWrapper backupMethod, Nullable`1 jobRunID)
Going for next try
26/09/2008 01:52:06
Max tries = 0
26/09/2008 01:52:10
Please let us know when this is resolved. In the mean time we've
implemented a re-try ordering a new report if the download url throws
404 not found. The problem with this is we are paying quota for each
new report although the problem is not on our side.
The bug is in with the engineering team, but there's no update on it
yet. How frequently are folks experiencing this behavior over the past
day or so? If this was taking place primarily last week that's a good
data point to pass back to the engineers.
Cheers,
-Jeff Posnick, AdWords API Team
On Sep 29, 4:35 am, Albert <albert.ben...@gmail.com> wrote:
> Please let us know when this is resolved. In the mean time we've
> implemented a re-try ordering a new report if the download url throws
> 404 not found. The problem with this is we are paying quota for each
> new report although the problem is not on our side.
> The bug is in with the engineering team, but there's no update on it
> yet. How frequently are folks experiencing this behavior over the past
> day or so? If this was taking place primarily last week that's a good
> data point to pass back to the engineers.
> Cheers,
> -Jeff Posnick, AdWords API Team
> On Sep 29, 4:35 am, Albert <albert.ben...@gmail.com> wrote:
> > Please let us know when this is resolved. In the mean time we've
> > implemented a re-try ordering a new report if the download url throws
> > 404 not found. The problem with this is we are paying quota for each
> > new report although the problem is not on our side.
I wanted to update folks after speaking to the engineering team about
this again.
There's speculation that these bad URLs might be returned during a
period of time in which the backend datastore is in a particular state
(apologies for not being able to get more specific than that). They're
matching up the timestamps from the sample failures everyone has
already provided, but what they'd really like is to be notified the
next time this happens so that they could try to catch things live.
So, please don't hesitate to post again about this behavior soon after
you see it. I'll bring it to the engineers' immediate attention when
you do.
Cheers,
-Jeff Posnick, AdWords API Team
On Oct 2, 1:19 pm, tozor <t...@adlucent.com> wrote:
> I saw it several times on Friday during the day, but have not seen it
> since then.
> Tim Ozor
> On Oct 2, 10:07 am, AdWords API Advisor <adwordsapiadvi...@google.com>
> wrote:
> > Hello,
> > The bug is in with the engineering team, but there's no update on it
> > yet. How frequently are folks experiencing this behavior over the past
> > day or so? If this was taking place primarily last week that's a good
> > data point to pass back to the engineers.
> > Cheers,
> > -Jeff Posnick, AdWords API Team
> > On Sep 29, 4:35 am, Albert <albert.ben...@gmail.com> wrote:
> > > Please let us know when this is resolved. In the mean time we've
> > > implemented a re-try ordering a new report if the download url throws
> > > 404 not found. The problem with this is we are paying quota for each
> > > new report although the problem is not on our side.
<adwordsapiadvi...@google.com> wrote:
> I wanted to update folks after speaking to the engineering team about
> this again.
> There's speculation that these bad URLs might be returned during a
> period of time in which the backend datastore is in a particular state
> (apologies for not being able to get more specific than that). They're
> matching up the timestamps from the sample failures everyone has
> already provided, but what they'd really like is to be notified the
> next time this happens so that they could try to catch things live.
> So, please don't hesitate to post again about this behavior soon after
> you see it. I'll bring it to the engineers' immediate attention when
> you do.
> Cheers,
> -Jeff Posnick, AdWords API Team
> On Oct 2, 1:19 pm, tozor <t...@adlucent.com> wrote:
> > I saw it several times on Friday during the day, but have not seen it
> > since then.
> > Tim Ozor
> > On Oct 2, 10:07 am, AdWords API Advisor <adwordsapiadvi...@google.com>
> > wrote:
> > > Hello,
> > > The bug is in with the engineering team, but there's no update on it
> > > yet. How frequently are folks experiencing this behavior over the past
> > > day or so? If this was taking place primarily last week that's a good
> > > data point to pass back to the engineers.
> > > Cheers,
> > > -Jeff Posnick, AdWords API Team
> > > On Sep 29, 4:35 am, Albert <albert.ben...@gmail.com> wrote:
> > > > Please let us know when this is resolved. In the mean time we've
> > > > implemented a re-try ordering a new report if the download url throws
> > > > 404 not found. The problem with this is we are paying quota for each
> > > > new report although the problem is not on our side.
So yesterday's occurrence is actually something that the core
engineering team knows the root cause of. There was a loss of
connectivity between one particular set of AdWords API servers and the
backend data store that contains reports data yesterday morning for
several hours. There is retry/failover logic in place that should have
protected most users from seeing anything other than slightly
increased response times, but they did see a handful of outright
failures to fetch report data due to this.
But... it's not a type of failure that has occurred previously, so
the engineering team isn't convinced that it has particular insight to
offer into the root cause of the previous occurrences. \
Cheers,
-Jeff Posnick, AdWords API Team
On Nov 24, 6:32 pm, tozor <t...@adlucent.com> wrote:
> We had a reoccurence of this error at 7:30AM PST.
> Thanks.
> Tim Ozor
> On Oct 14, 12:30 pm, AdWords API Advisor
> <adwordsapiadvi...@google.com> wrote:
> > I wanted to update folks after speaking to the engineering team about
> > this again.
> > There's speculation that these bad URLs might be returned during a
> > period of time in which the backend datastore is in a particular state
> > (apologies for not being able to get more specific than that). They're
> > matching up the timestamps from the sample failures everyone has
> > already provided, but what they'd really like is to be notified the
> > next time this happens so that they could try to catch things live.
> > So, please don't hesitate to post again about this behavior soon after
> > you see it. I'll bring it to the engineers' immediate attention when
> > you do.
> > Cheers,
> > -Jeff Posnick, AdWords API Team
> > On Oct 2, 1:19 pm, tozor <t...@adlucent.com> wrote:
> > > I saw it several times on Friday during the day, but have not seen it
> > > since then.
> > > Tim Ozor
> > > On Oct 2, 10:07 am, AdWords API Advisor <adwordsapiadvi...@google.com>
> > > wrote:
> > > > Hello,
> > > > The bug is in with the engineering team, but there's no update on it
> > > > yet. How frequently are folks experiencing this behavior over the past
> > > > day or so? If this was taking place primarily last week that's a good
> > > > data point to pass back to the engineers.
> > > > Cheers,
> > > > -Jeff Posnick, AdWords API Team
> > > > On Sep 29, 4:35 am, Albert <albert.ben...@gmail.com> wrote:
> > > > > Please let us know when this is resolved. In the mean time we've
> > > > > implemented a re-try ordering a new report if the download url throws
> > > > > 404 not found. The problem with this is we are paying quota for each
> > > > > new report although the problem is not on our side.
|
