| Table of Contents |
|---|
...
Why are the changes I did to the Response Content Type resource parameter of a published API not reflected in the API Store, even after saving?
If you edited the Response Content Type using the UI, please open the API's Swagger definition, do your changes, and save. Then the changes should be reflected back in the API Store. This will be fixed in a future release.
...
To disable the self signup capability, open the API-M management console and click the Resources > Browse menu. The registry opens. Navigate to the /_system/governance/apimgt/applicationdata/sign-up-config.xml file and set the <SelfSignUp><Enabled> element the element to false. To engage your own signup process, see Adding a User Signup Workflow.
...
To resolve this issue, first access the Gateway URL via a new browser tab of the same browser and accept the certificate from the browser.
I get a Hostname
...
verification failedexception when trying to send requests to a secured endpoint. What should I do?
Set the <parameter name="HostnameVerifier"> element to AllowAll in <API-M_HOME>/repository/conf/axis2/axis2.xml file's HTTPS transport sender configuration. For example, <parameter name="HostnameVerifier">AllowAll</parameter>.
...
| Tip |
|---|
If you are using the API-M instance you used as the first instance in the Publish through Multiple API Gateways tutorial, you may receive the above error when trying out other tutorials. This is because you updated the environments configurations in that pack by adding two API Gateway environments under the <Environments> element, and commenting the <environment> element that comes by default. To overcome this error, uncomment the default configuration and delete the newly added configuration under <Environments> in the <API-M>/repository/conf/api-manager.xml file. |
How can I capture the state of a system?
...
Why does a timeout occur between the client and WSO2API-M connection before API Manager sends the response to the client?
The following are two possible reasons behind this timeout.
- The backend not being available.
- The backend may be slow
There are two socket timeouts, connection timeout and read timeout.
The connection timeout is the timeout in making the initial connection (i.e., completing the TCP connection handshake). The read timeout is the timeout on waiting to read the data. A read timeout error occurs if the server fails to send a byte seconds after the last byte.
The http.connection.timeout and http.socket.timeout are two different configurations that are defined in the <API-M_HOME>/repository/conf/passthru-http.properties file to handle the connection timeout and read timeout for sockets respectively.
http.connection.timeout defines a max time period to establish a connection with the remote host, and the http.socket.timeout defines the time waiting period for data after establishing the connection, which relates to the maximum time of inactivity between two data packets.
Therefore, you can maintain a high value for the http.socket.timeout parameter to avoid a connection read timeout related error. Thereby, you can increase the endpoint timeout value accordingly.
Example:
By default the socket timeout value (the socket timeout for the HTTP listener) is 60 seconds. If you observe a socket timeout error in your error logs, it means that the backend is taking longer than 60 seconds to respond.
Therefore, you can increase the socket timeout of the passthrough HTTP transport in the <API-M_HOME>/repository/conf/passthru-http.properties file to 120 seconds (http.socket.timeout=120000).
Usually, you would not need a high value for the HTTP connection timeout (http.connection.timeout), because it is expected to establish a connection with a server within 10 to 20 seconds. However, if it takes longer, you need to work on scaling the backend as it can not handle the current load that you are expecting.
How can I capture the state of a system?
At the time of an error, you can use a tool called Carbon Dump (carbondump.sh) to collect all the necessary data (i.e., heap and thread dumps) from a running WSO2 API Manager instance in order to carryout a head dump and thread stack analysis. For more information on using this tool, see Capturing the state of the system in the Administration guide.
...
The REG_LOG table contains all the registry operations performed for all the registry resources in the system. When you clean up this table, you need to keep the latest record from every resource path to maintain atleast at least one resource reference in case of reindexing. Exceute Execute the following query to clean this table.
...