WSO2 API Manager needs to restart after creating and publishing a new API in the new version (4.1.O). In old versions, there is no need to restart it.
Do you have a distributed API Manager deployment (not an all-in-one setup)? I suspect there could be a misconfiguration between the Control plane and the gateway node. Better to verify the configurations first (refer [1]).
In a distributed setup, gateway nodes listen to a JMS topic in the control plane. when API is deployed, gateway gets an event and after that, it queries the CP and gets the API-related artifacts. I suspect this CP->GW event is not reaching the gateway. As a result, APIs are not deployed in the gateway and cannot invoke it.
Gateway node does not keep the API artifacts stored. When there is a restart, gateway node calls the control plane directly and gets the available API-related artifacts and deploys them. That is why it works when you restart the gateway.
This is the new event-based mechanism we use in the APIM versions 3.2 onwards. That is why it worked in old versions.
[1] https://apim.docs.wso2.com/en/latest/install-and-setup/setup/distributed-deployment/deploying-wso2-api-m-in-a-distributed-setup/
Related
new resources defined in rest api doesn't get synced in wso2 api manger and when I call the resource face 404 not found error,what is the problem?
You need to explain a little bit on your process here.
If you are using APIM latest version (4.0.0 or 4.1.0), we have decoupled API Publishing and deploy in the gateway in to two. All the runtime changes you have added to the API (Endpoints, mediations, resource changes) will not be synced with API update, but you need to create a new revision and deploy that revision in the gateway.
If you have already created a revision and deployed, yet still resource is not accessible, then you need to investigate the CP and gateway connectivity, or gateway deployed artifacts.
You can check the deployed artifacts with Gateway rest API.
I've tried working on the API Manager subscription workflow in a single instance and it's working fine. Now I want the same to be performed on a distributed deployment environment. Can I know on which node shall I update the SubscriptionCallbackService.epr path and on which node I should enable the " Engaging the WS Workflow Executor in the API Manager ".
Note:
We are using EI 6.5.0 and APIM 2.6.0 and 3.1.0 in two different environments.
You need to copy the <API-M_HOME>/business-processes/epr (any of the apim nodes) folder to <EI_HOME>/wso2/business-process/repository/conf/epr, SubscriptionCallbackService following value should be updated, Gateway port is 8243 if you have not done any offset.
<wsa:Address>https://<APIM_GATEWAY_IP>:PORT/services/WorkflowCallbackService</wsa:Address>
"Engaging the WS Workflow Executor in the API Manager" should be done in the devportal node
We are designing wso2 apim 2.0 cluster deployment architecture, from 2.0 clustering, we just found distribution deployment description, so
Is the wso2 apim gateway 2.0 cluster same with 1.10?
Any recommendation for system CPU/MEMORY requirement?
wso2 apim 2.0 has traffic manager, how to cluster it?
For store/publisher, how to cluster them?
When integration with APIM Analytics, do we just need to config gateway workers?
1) There are configuration changes, and also new configs, in gateways. But gateway clustering has not been changed.
2) See Installation Prerequisites and Tuning Performance
3) There is no public document yet. It'll be there soon. Until now, you can cluster it in the same way gateways are clustered.
4) Store and publisher should be in the same cluster.
5) Gateway workers, store and publisher
Update:
About Dep-Sync: In gateway worker-manager setup, we only publish API synapse files to manager node, and then use dep-sync to copy those APIs to gateway workers. You can use anything that can sync artifacts between nodes instead of SVN based dep-sync. (eg. rsync)
I have a question on WSO2 API Manager Clustering. I have gone through the deployment documentation in detail and understand the distributed deployment concept where in one can seggregate the publisher, store, key manager and gateway. But as per my asessment, that makes the deployment architecture pretty complex to maintain. So I would like to have a simpler deployment.
What I have tested is to simply have two different instances of the WSO2 API Manager to run in two different boxes pointing to the same underlying data sources in MySQL. What I have seen is that, the API calls work perfectly and the tokens obtained from one WSO2 instance would work for API invocation on the other API Manager instance. The only issue with this model is that we need to deploy the APIs from individual publisher components for as many WSO2 API Manager instances that are running. I am fine to do that since the publishing will be done by one single small team. We will have a hardware load balancer in front having the API endpoint URLs and token endpoint URLs for both the API managers and the harware LB will do the load balancing.
So my question is - are there any problems in following this simple approach from the RUNTIME perspective? Does the clustering add any benefit from RUNTIME perspective for WSO2 API Manager?
Thank you.
Your approach has following drawbacks (there can be more which I do not know);
It is not scalable. Meaning - you can't independently scale (adding more instances of) store or publisher or gateway or key manager.
Distributed throttling won't work. It will lead to throttling inconsistencies since the throttling replication won't happen if you don't enable clustering. Lets say you define 'Gold' tier for an API. Doesn't matter how many gateway instances you are using, a user should be restricted to access no more than 20req/min to this API. This should have been implemented based on a distributed counter (not sure the exact implementation details). So if you don't enable clustering, one gateway node doesn't know the number of requests served by other gateway nodes. So each gateway node will have their own throttle counter. Meaning - a user might be able to access your API more than 20req/min. So this is one of the throttling inconsistencies. Further, lets say one gateway node is throttled out a user but the other gateway node is not. Now, if your LB routes the request to 1st gateway node, user will not be able to access the API. If your LB routes the request to 2nd gateway node, user will be able to access the API. This is another instance of throttling inconsistency. To overcome all these issues, you just need to replicate the throttling across all the gateway nodes by enabling clustering.
Distributed caching won't work. For example, API Key validation information are cached. If you revoke a token in one API Manager node, cache will be cleared in that node. So a user can't use revoked token via that API Manager node, BUT he is able to use the token via the other API Manager node until the cache is invalidated (I guess 15 min by default). This is just one instance where things can go wrong if you don't cluster your API Manager instances. To solve these issues, you just need to enable clustering, then the cache will be in sync across the cluster. Read this doc for more details on various caching available in WSO2 API Manager.
You will be having several issues if you don't have above features. WSO2 highly recommends distributed deployment in production.
I have configured 2 wso2 api gateways (say gw1 and gw2) behind a load balancer (say lb1) . I have configured publisher in another node( say pub1). In pub1 box /etc/hosts file I have api gateway url to that of lb1. Now whenever I update or add a new api on pub1 it does not get immediately reflected on both gw1 and gw2, it gets reflected on one of the two. Is there a way programtically force api manager to refresh the list of published api's?
You need us deployment synchronizer to sync the artifacts across the gateway nodes. In your scenario, one gateway will need to be treated as the manager whilst the other one as the worker node.
Pls refer the documentation here on how to configure deployment synchronizer.