We currently started using WSo2 API Manager load balance (LB) option for microservices High Availability.
Is it a good idea to use WSO2 LB? Or Instead of WSO2 LB, should we opt for Nginx? (which we also use for other LB requirements.)
Will the performance of WSO2 API Manager degrade if we choose to use WSO2 LB?
Any recommended links that we can follow to do the WSO2 LB settings? Our current configuration is causing Heap space issues and we are suspecting our "Advanced Endpoint Configuration". We want to have endpoint suspension if something goes wrong with one of the Micro service VM's. It would be great if someone is kind enough to share the recommended configs for production use case.
Best Regards,
Rithesh
Is it a good idea to use WSO2 LB? Or Instead of WSO2 LB, should we opt for Nginx? (which we also use for other LB requirements.)
I believe the WSO2 LB is considered obsolete and there is really no reason why not to use anything else (nginx, httpd, haproxy,..). Even there is NGINX config somewhere on WSO2 docs site, just search for it
Our current configuration is causing Heap space issues and we are suspecting our "Advanced Endpoint Configuration".
Without any more "advanced" information, such as profiling, it is impossible to say what is your problem. The cause could be some custom endpoints, logging the payload, transformations, ...
Just setting the advanced properties won't cause OOM
recommended configs for production use case
The defaults are just find for most of production use cases. Without more information you will get only opinions
Related
Currently, We are using WSO2(v5.8) in our development environment. We have used all the soap request almost of WSO2 - tenant creation, service provider, user store, and claim as well. All the soap requests are working fine. But in case of Claim : the problem is , it created successfully and updated successfully using soap request without any error. When we are going to see the new added claim on wso2 console then the newly added claims are not displaying under claims. After sometime the claims are available, which means we are able to see the newly added claim and we can use it with service provider also.
But most of the time is not displaying. I think the claims are not synced properly in case of multiple instances running of WSO2. Somebody help highly appreciated
Historically WSO2 Identity Server used distributed caching to utilize the above-mentioned advantages as well as to minimize the coherence problem. However, in newer deployment patterns where the network is not tightly controlled, distributed caching fails in unexpected ways. Hence, we no longer recommend using distributed caching. Instead, it is recommended to have local caches.
Refer to this document to get further information about deployment patterns.
In order to enable localcaches, Please check whether you have enabled this property in /repository/conf/carbon.xml file
<ForceLocalCache>true</ForceLocalCache>
For clustered nodes, enabling this property enables local cache invalidations.
[update]
There is a similar issue already reported regarding claims are not listed or not synced properly in a clustered environment when forcelocalcache is enabled. You can refer to the git issue here. This issue is fixed with Identity Server 5.9.0
I would like to implement WSO2 as Identity and Access Management on a server to control some small business users. It's a project for the vocational school. It would be possible for free? I'm sorry but I'm a bit lost with all this.
Thank you very much in advance,
WSO2 as Identity and Access Management on a server to control some small business users
Indeed WSO2 Identity Server (wso2is) is intended for that. The applications on the server will have to use an authorization protocol (SAML, OAuth, ..) to enforce the user access.
Without any more specific questions / information about your case you probably won't get any more specific answer.
It would be possible for free?
It depends.
Indeed, WSO2 products are open source, so you can use them freely and update them as you wish.
On the other hand some institutions require to have supported all deployed products, so you should check what rules apply to your case.
As well you may consider subscription to help you stay current with patches and updates, however it depends on your policies and budget.
WSO2 Carbon is not officially supported in webapp mode (see the selected answer here). However, I have no choice - If I want to run carbon, it must be run in webapp mode.
There are some detailed instructions here for setting up carbon 4.x in webapp mode.
I am concerned is that standalone mode is strongly recommended by WSO2.
My Questions are: What are the limitations:
when running Carbon 4.x in webapp mode?
when running other Carbon based products (e.g. ESB, AS, etc) in webapp mode?
If possible, please provide a detailed list of the limitations.
Limitations:
When you take the ESB, as you might have seen it exposes ports 8280/8243 (HTTP/HTTPS) in addition to 9763/9443 which is exposed through the servlet transport. In the case of ESB you need (and want) to use port 8280/8243 when you're interacting with the ESB because those are the two non-blocking high performant transports. When you deploy ESB on top of another web container, you're limited by the servlet transports provided by the container. So we can't get the desired performance out of the ESB for proxying and other scenarios.
Complexities involving using web container functionalities. Carbon has its own clustering/caching/security etc... infrastructure. When you deploy Carbon as a webapp then we should look at supporting all those functions provided by the container for different containers. Which is complex, not consistent and in some cases sub-optimal
IMHO those were the two most important factors why it's discouraged to deploy Carbon on top of other containers. Going with a standalone deployment approach it has contributed immensely to not include web container specific "hacks" into the platform to get things done and have a much cleaner consistent platform.
One issues with deploying Carbon in web-app mode is that this deployment model is not supported by WSO2. I will add more issues to this answer as I encounter them...
AFAIK, webapp is not supported... Please refer this thread :Running WSO2 Carbon as Web Application in Tomcat
Regards,
Mohan
I would like to know is the WSO2 ESB Version 4.5.1 installation out of the box production ready in terms of configuration, If no, can someone give me some hints, would like to know what to turn off in a production environment.
All the WSO2 products are production compatible out-of-the-box in general. But if you are using with distributed setup you may need to setup server in clusters with backend-frontend separation. And also you may need to use WSO2 Elastic Load Balancer. And the default embedded H2 database will not be efficient and you may need to change to MySQL.
Anyway if you are using a small setup in production all of them may not needed.
Could someone please tell me how to access CRM (IFD) webservices from outside the domain?
First you'll have to set up the instance for IFD support. Microsoft has an IFD setup tool.
You'll then want to make sure your website is exposed to the internet. It sounds like you can successfully ping it from the above comments.
You can then use the web services if you provide the appropriate url and network credentials.
service.Credentials = new System.Net.NetworkCredential("username",
"pass#word1", "domain");
A VPN setup is often a good way to accomplish this. That will involve opening the appropriate ports in your (or your company's) firewall, as well.
thats exactly what i did and i found out that theres nothing wrong with the way i access the web services but sommeone has turned off basic authentication of the CRM application, turned it back on and problem is solved
actually if you right click on the website(from iis) and go into the security section, it lets you select the authentication type , eg: anonymous, basic or windows. you should not require to turn off the authentication in CRM, as i found out you need to have basic authentication enabled in order to access remotely.
regards,
lasa