This morning all of my code that uses Watson Conversation suddenly stopped working. I get this error in the console:
{ Error: Classification Error: Protocol error
at Request._callback (D:\home\site\wwwroot\node_modules\watson-developer-cloud\lib\requestwrapper.js:99:21)
at Request.self.callback (D:\home\site\wwwroot\node_modules\request\request.js:186:22)
at emitTwo (events.js:126:13)
at Request.emit (events.js:214:7)
at Request. (D:\home\site\wwwroot\node_modules\request\request.js:1163:10)
at emitOne (events.js:116:13)
at Request.emit (events.js:211:7)
at Gunzip. (D:\home\site\wwwroot\node_modules\request\request.js:1085:12)
at Object.onceWrapper (events.js:313:30)
at emitNone (events.js:111:20)
code: 500,
error: 'Classification Error: Protocol error',
'x-global-transaction-id': '7ecac92c5aa8813805dfb888' }
I did not change any of my code recently. So I assumed it must be a problem with IBM Watson, or am I doing something wrong?
Found it. It seems to be an outage of the Watson Conversation service.
https://console.bluemix.net/status/notification/ae744d684432a9086528e8c9a4c21033
Users of the Watson Conversation service are experiencing elevated error rates when attempting to use the service. The team is aware and is working to resolve.
2018-03-14 0148 UTC: Added United Kingdom and Sydney regions to affected list.
Update: it keeps happening occasionally, I've even written code to retry automatically a few times, but it doesn't help. Seems the Watson service is simply down for a couple of minutes at a time.
Update: happening again on December 10, 2018.
Related
Encountered and solved this problem. Posting for posterity since my situation differed from the usual.
Important: I am running a derivative of Ubuntu in a VirtualBox VM on a freshly installed Windows host.
The Problem
When creating a new react amplify project using create-react-app, amplify init fails with an InvalidSignatureException after selecting a profile:
$ amplify init
...
For more information on AWS Profiles, see:
https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html
? Please choose the profile you want to use default
InvalidSignatureException: Signature not yet current: 20220528T081112Z is still later than 20220528T051608Z (20220528T051108Z + 5 min.)
at Object.extractError (/snapshot/node_modules/aws-sdk/lib/protocol/json.js:52:27)
at Request.extractError (/snapshot/node_modules/aws-sdk/lib/protocol/rest_json.js:49:8)
at Request.callListeners (/snapshot/node_modules/aws-sdk/lib/sequential_executor.js:106:20)
at Request.emit (/snapshot/node_modules/aws-sdk/lib/sequential_executor.js:78:10)
...
at IncomingMessage.EventEmitter.emit (domain.js:483:12)
at endReadableNT (_stream_readable.js:1241:12)
at processTicksAndRejections (internal/process/task_queues.js:84:21) {
code: 'InvalidSignatureException',
time: 2022-05-28T08:11:12.872Z,
requestId: 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX',
statusCode: 403,
retryable: false,
retryDelay: 35.74742577991159
}
I also experienced errors with amplify push and amplify pull complaining about things such as "Time skew" and "Timeouts", and AWS Console threw "List apps call failed: Network Error".
Similar Posts
Here are a sample of posts discussing similar problems.
'amplify init' keeps failing
https://github.com/aws-amplify/amplify-js/issues/2014
https://github.com/concourse/s3-resource/issues/34
https://github.com/aws-amplify/amplify-hosting/issues/2417
Failed ideas
Sample of failed ideas:
I tried creating a second project to see if problem persisted. It did.
I tried syncing my time via ntp, ntpdate, ntpd. Same error.
I tried setting time via GUI. Failed to set. Same error.
Story leading to solution
At this point, I noticed my time occasionally jumps on sync with ntpd. Actual time was 01:40; on sync, it jump to 04:40, then back to 01:40. This would occur intermittently on sync. Timezones were set correctly. Trial and error exhausts my ideas, so I return to my host. Host time is 01:40, but discord messages are timestamping at 10:40. Wait.
Windows host timezone was set to UTC-8:00 Pacific Time. VirtualBox Linux guest was set to UTC-5:00 Eastern Time. Oddly, both were displaying 01:40.
Steps to resolve
Set host timezone to UTC-5:00 Eastern Time
Sync Clock in "Time and Date" settings in Windows
Disable/uninstall ntp from Linux guest
Issue was resolved. amplify init succeeded.
We implemented Dependency-check-maven and this was working fine up till now. But suddenly getting this error now,
[WARNING] An error occurred while analyzing 'oldui/includes/ckeditor/lang/no.js' (Sonatype OSS Index Analyzer).
Not sure where this is originating from?
I think the reason is due to https://ossindex.sonatype.org/ certificate is expired on 25th May. When you go to that website, you can see that you get the SSL error.
I have a fairly busy SSRS Instance and the redering performance is consistently degrading to the point where we have set the recyle time config to 60 as work around and im still getting significant reduction in rendering performance within the hour. once the 60 minutes passes the performance goes back to an acceptable level and begins to degrade once more.
I have played with the memory settings within the config but it doesnt seem to have made a difference. The server is dedicated to SSRS and there doesnt seem to be any memory pressure. at this second theres 32gb of memory and 28gb free with SSRS using around a gig.
Looking in the log we have a lot of the following error
httpruntime!ReportServer_0-193!2b84!05/17/2018-15:14:52:: e ERROR: Failed to
create worker request: pipeline=0x56C27945E0, exception=Microsoft.ReportingServices.Diagnostics.Utilities.ReportServerHttpRuntimeInternalException: An internal or system error occurred in the HTTP Runtime object for application domain ReportServer_INST130_0-193-131710375157483972. ---> Microsoft.ReportingServices.Diagnostics.Utilities.ReportServerHttpRuntimeException: An error occurred in the HTTP Runtime object for application domain ReportServer_INST130_0-193-131710375157483972. Most likely, the HTTP request contains an unsupported verb or invalid syntax.
rshost!rshost!2b84!05/17/2018-15:14:52:: e ERROR: HttpPipelineCallback::SendResponse(): failed writing response.
rshost!rshost!2b84!05/17/2018-15:14:52:: e ERROR: Failed with win32 error 0x10DD, pipeline=0x00000056C27945E0.
httpruntime!ReportServer_0-193!2b84!05/17/2018-15:14:52:: i INFO: RsHttpRuntime::ProcessRequest(): calling EndOfRequest() from exception handler of worker request constructor. Runtime=ReportServer_INST130_0-193-131710375157483972. Pipeline=0x56C27945E0.
rshost!rshost!2b84!05/17/2018-15:14:52:: e ERROR: Failed to process request 0x800710dd, pipeline=0x00000056C27945E0.
library!ReportServer_0-193!2218!05/17/2018-15:14:53:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ReportServerHttpRuntimeException: Unsupported HTTP verb 3., Microsoft.ReportingServices.Diagnostics.Utilities.ReportServerHttpRuntimeException: An error occurred in the HTTP Runtime object for application domain ReportServer_INST130_0-193-131710375157483972. Most likely, the HTTP request contains an unsupported verb or invalid syntax.;
library!ReportServer_0-193!2218!05/17/2018-15:14:53:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ReportServerHttpRuntimeInternalException: Failed to fill worker request, Microsoft.ReportingServices.Diagnostics.Utilities.ReportServerHttpRuntimeInternalException: An internal or system error occurred in the HTTP Runtime object for application domain ReportServer_INST130_0-193-131710375157483972. ---> Microsoft.ReportingServices.Diagnostics.Utilities.ReportServerHttpRuntimeException: An error occurred in the HTTP Runtime object for application domain ReportServer_INST130_0-193-131710375157483972. Most likely, the HTTP request contains an unsupported verb or invalid syntax.
at ReportingServicesHttpRuntime.BaseWorkerRequest.FillWorkerRequest()
I have been looking into this on and off for a while and im coming up blank.
Try turning on the Report Server HTTP Log.
You can then cross reference when the error occurs in the trace log, with the request that was logged in the HTTP log.
Note that the timestamps in the trace log use local time, while the timestamps in the HTTP log use GMT.
I have the same issue as you and found that unsupported verb was OPTIONS, which looks like it is being sent by a Microsoft Office application:
11/21/2018 22:04:17 xx.xx.xx.xx DOMAIN\user xx.xx.xx.xx 20480 ssrsServer OPTIONS /Reports/Pages/ 405 2589 0 1.1 Microsoft Office Protocol Discovery - - -
I have not yet been able to determine how I can stop this error.
Our deployments for the default module of a particular app are failing, seemingly at random, at least 50% of the time, which is constantly disrupting our workflow.
With verbose logging turned on via appcfg.py update app.yaml --verbose, this error appears on the terminal:
03:43 PM Uploaded 4 files and blobs.
03:43 PM Compilation starting.
2015-09-23 15:43:51,886 INFO appcfg.py:1735 Send: /api/appversion/precompile, params={'version': 'myversion', 'app_id': 'myappid', 'module': 'default'}
03:43 PM Compilation completed.
03:43 PM Starting deployment.
2015-09-23 15:43:54,215 INFO appcfg.py:1735 Send: /api/appversion/deploy, params={'version': 'myversion', 'app_id': 'myappid', 'module': 'default'}
2015-09-23 15:43:56,341 INFO appcfg.py:2601 HTTP Error (HTTP Error 400: Bad Request Unexpected HTTP status 400)
03:43 PM Rolling back the update.
2015-09-23 15:43:56,341 INFO appcfg.py:1735 Send: /api/appversion/rollback, params={'version': 'myversion', 'app_id': 'myappid', 'module': 'default'}
Error 400: --- begin server output ---
Client Error (400)
The request is invalid for an unspecified reason.
--- end server output ---
The failure is extremely consistent, in that most of the time we try deploying the module after not having deployed for a few hours, the deployment attempt will fail with the above output.
Then, without changing any app code, retrying the deployment usually succeeds (but at times, the second attempt also fails, requiring subsequent deployment attempts).
This problem started happening earlier this year. Once the problem started occurring, it has not ceased. Before it occurred, we had no no issues with deployments.
The version of the module being deployed has no effect on the rate of deployment success. We are using the Python runtime for this module.
I have already emailed a Solutions Architect from Google about this, but apart from upgrading to a paid support plan to ensure someone looks into this, he suggested I post on here with the hope that the App Engine support team gets back to me.
App Engine support team - can you find out what is going on (and ideally provide a fix)? If you need more information (such as my app ID), please let me know.
I'm using richface 4.3.0.M2 and it's throwing the exception below when I run with GAE 1.7.3 and GAE 1.7.4. However, it works fine with GAE 1.7.2.
Any help or workarounds available?
INFO: request=com.google.appengine.tools.development.ResponseRewriterFilter$RequestWrapper#14e834c, response=com.google.appengine.tools.development.ResponseRewriterFilter$ResponseWrapper#18e2fc5, chain=Faces Servlet
14/12/2012 2:01:35 AM com.google.apphosting.utils.jetty.JettyLogger warn
WARNING: /javax.faces.resource/application.css.jsf
java.lang.NumberFormatException: Wed, 05 Dec 2012 23:22:19 GMT
at org.mortbay.io.BufferUtil.toLong(BufferUtil.java:106)
at org.mortbay.jetty.HttpFields$Field.getLongValue(HttpFields.java:1479)
at org.mortbay.jetty.HttpFields.getLongField(HttpFields.java:720)
at org.mortbay.jetty.Request.getIntHeader(Request.java:728)
at javax.servlet.http.HttpServletRequestWrapper.getIntHeader(HttpServletRequestWrapper.java:106)
at
I found out that it's a pending problem with google app engine. The issue page can be found here. They offer a workaround which does fix this problem, though it has not yet been fixed formally.
Similar question made here.