For the past few days i have been trying to access my discovery profile but it is showing -- 408 API request has timed out, I don't understand what it is i tried on different browsers and different systems.
A 408 HTTP response code is admittedly confusing in this case as 400-level errors typically indicate the client (browser) took too long to send the necessary information so the server timed out the connection when a preconfigured duration has been exceeded.
In this particular case, however, a 502 Gateway Timeout HTTP response would be more appropriate. There are multiple complex interactions happening with some of the pages in Watson Discovery Tooling and sometimes the service experiences slowness. In general, I would investigate the status page for the affected IBM Cloud services to determine whether or not there are any customer impacting events.
To check the status of Watson Discovery and any IBM provided service, I would check https://console.bluemix.net/status to see if any of the slowness or errors line up with your experiences.
Related
I have a node js app in mongodb cloud platform,which will be used for posting 1 million messages to a topic in GCP pubsub.Since the platform is not supporting the npm package #google-cloud/pubsub,we implemented it using the API reference for Pubsub.Upon load testing the app,I can see each message is taking 50 seconds for posting it to the topic.Ideally it should take less than 5 secs.It takes around 30 seconds for the access_token API call and 20 seconds for the message posting API call.Since each message posting is a independent event,we cannot maintain a session to store the access_token and reuse it and API_KEY authentication method is not available for GCP PubSub.Is the API method for gcp pubsub is very slow when compared to using library #google-cloud/pubsub ?.
Can anyone suggest a solution to improve performance of GCP PubSub using APIs
The PubSub client library are greatly optimized in several ways. The first one is the use of gRPC protocol instead of REST API. Then, there is message aggregation before a push to PubSub (500ms of wait by default). Then, there is various async mechanism to parallelize the processing.
So, a huge and great work done by the Client Library teams and hard (or expensive) to reproduce on your side. But you can, the sources are public, you can have a look to the client libraries!
The 30s for the access_token retrieval is too long. Are you sure that you haven't network issue? In any case, this token is valid for 1H. If you can reuse it in your subsequent call you will save a lot of time!
I have a small hobby project using Google Cloud's Natural Language Processing API. I also made sure to set up a daily budget for the project of just $2.00 USD.
My questions is: what happens when/if the spending limit is reached? Does the API cease working to prevent any further queries to the API? Basically, does having a spending limit prevent me from having to worry about additional charges to the project in question?
Thanks!
Yes, if your daily spending limit is hit, services that cost money will cease to function until the limit resets.
See When a resource is depleted for details:
For resources that are required to initiate a request, when the resource is depleted, App Engine by default returns an HTTP 403 or 503 error code for the request instead of calling a request handler.
For all other resources, when the resource is depleted, an attempt in the application to consume the resource results in an exception. This exception can be caught by the application and handled, such as by displaying a friendly error message to the user.
In the Python API, this exception is apiproxy_errors.OverQuotaError.
In the API for Java, this exception is com.google.apphosting.api.ApiProxy.OverQuotaException.
In the Go API, the appengine.IsOverQuota function reports whether an error represents an API call failure due to insufficient available quota.
Earlier today I noticed the following error in my logs:
503 Too many outstanding pull requests for subscription '<...>'.
Please reduce the number of simultaneous Pull() requests invoked for
this subscription. (POST https://pubsub.googleapis.com/v1/projects/<...>:pull)
I tried searching for the exact quantity of allowed simultaneous pull requests, but can't seem to find it anywhere. The only mention of this error I find is here in the docs, but again, no numbers are stated.
I have 40 processes pulling from the subscription.
This error happens when there is a transient overload on a specific instance of a Cloud Pub/Sub server to which some of your requests are being routed. The error message is admittedly poor and should not tell you to reduce your pull requests and I will remedy that.
I'm attempting to do some stress testing on my GAE application
to see how it's performance holds up with a large number of
simultaneous users. I tried having a 100 threads each send an https
requests within 1 second, but half of them failed with a 503 status code the following
message:
"Error: Connection not allowed: reached maximum number of
connections."
This is a paid app, so I tried upgrading the instance class and
setting up some idle instances, but it doesn't seem to make any
difference.
Is there a limit on the number of simultaneous connections? Or is
this because all the requests are generated from the same host?
Thanks
EDIT: Response to Kyle: I'm using jmeter and sending 100 simultaneous requests to google.com doesn't ahve any issues.
Response to Nick: I'm not expecting individual clients to send lots of simultaneous requests, I was trying to simulate 100 users sending 1 request each.
Unbeknownst to me, a colleague had added a custom throttling filter to our application :) I removed this from the web.xml and it solves the problem.
we wrote in C++ a screen sharing application based on sending screenshots.
It works by establishing a TCP connection btw the server and client, where the server forwards every new screenshot received for a user through the connection, and this is popped-up by the client.
Now, we are trying to host this on google app engine, and therefore need 'servlet'-ize and 'sandbox' the server code, so to implement this forwarding through HTTP requests.
I immagine the following:
1. Post request with the screenshot as multiple-data form (apache uploads ..).
But now the server needs to contact the specified client (who is logged in) to send it/forward the screenshot.
I'm not sure how to 'initiate' such connection from the servlet to the client. The client doesn't run any servlet environment (of course).
I know HTTP 1.1 mantains a TCP connection, but it seems gapps won't let me use it.
1 approaches that comes to mind is to send a CONTINUE 100 to every logged in user at login, and respond with the screenshot once it arrives. Upon receival the client makes another request, and so on.
an alternative (insipired from setting the refresh header for a browser) would be to have the app pool on a regular basis (every 5 secs).
You're not going to be able to do this effectively on GAE.
Problem 1: All output is buffered until your handler returns.
Problem 2: Quotas & Limits:
Some features impose limits unrelated
to quotas to protect the stability of
the system. For example, when an
application is called to serve a web
request, it must issue a response
within 30 seconds. If the application
takes too long, the process is
terminated and the server returns an
error code to the user. The request
timeout is dynamic, and may be
shortened if a request handler reaches
its timeout frequently to conserve
resources.
Comet support is on the product roadmap, but to me your app still seems like a poor fit for a GAE application.
Long Polling is the concept used for such asynchronous communications between server and client.
In Long Polling, servlet keeps a map of client and associated messages. Key of Map being client id and value being list of messages to be sent to the client. When a client opens a connection with server (sends request to a servlet), the servlet checks the Map if there are any messages to be sent to it. If found, it sends the messages to the client exits from the method. On receiving messages, the client opens a new connection to the server. If the servlet does not find any messages for given client, it waits till the Map gets updated with messages for given client.
This is a late reply, I'm aware, but I believe that Google have an answer for this requirement: the Channel API.