Skip to main content

Posts

Showing posts from July, 2016

Create Application in WSO2 App Cloud via REST API

This blog post gives you some examples on how to use createApplication REST API correctly in WSO2 App Cloud  https://docs.wso2.com/display/AppCloud/Published+APIs Before invoke createApplication API, you need to login to the WSO2 App Cloud and get the session cookie. curl -c cookies -v -k -X POST -k https://apps.cloud.wso2.com/appmgt/site/blocks/user/login/ajax/login.jag -d 'action=login&userName=amalka.wso2.com@<tenant>&password=<password>’ This are some basic example to create applications in WSO2 App Cloud. Create application via upload from file system curl -v -k -b cookies -X POST https://apps.cloud.wso2.com/appmgt/site/blocks/application/application.jag -F action=createApplication -F applicationName=SampleFile -F applicationDescription=desc -F runtime=1 -F appTypeName=war -F applicationRevision=1.0.0 -F uploadedFileName=sample.war -F runtimeProperties=[] -F tags=[]  -F fileupload=@/home/amalka/Downloads/sample.war -F isFileAttached=true

WSO2 App Cloud Architecture

App Cloud SaaS application provides an user interface & REST API for app cloud users to deploy their application artifacts. The web UI is developed by Jaggery, and it invokes the REST API, which invokes following backend components to provide the app cloud solution. Docker Client provides an interface to build images and push to the docker registry. Kubernetes Client provides an interface to deploy applications in kubernetes cluster DAO provides an interface to manipulate database operations to store meta data required for App Cloud in App Cloud DB SOAP Client uses to invoke WSO2 Storage Server admin services to create databases and users WSO2 Application Server provides an hosting environment to deploy App Cloud SaaS application WSO2 Identity Server provides identity management configuring SSO with App Cloud SaaS application WSO2 Storage Server provides RSS instances for app cloud developers to store application data. WSO2 Data Analytics Serv

How commonauth service work with SSO in WSO2 Identity Server

Considering two SAML service providers configured under the same tenant, they are by default in single sing on, so after I login in Service provider A I can use the same browser to access Service provider B without inserting my credentials again. This blog explains in details how this happened with commonauth service during the second login What happens here is: On the first login to service provider A, it stores a cookie with a name "commonAuthId" When the first request comes; DefaultRequestCoordinator.handle() [1] method invokes DefaultAuthenticationRequestHandler.handle() method, see [2] within the DefaultAuthenticationRequestHandler.handle() it invokes concludeFlow() private method [3] , that sets the 'commonAuthId' cookie via setAuthCookie() method [4] private void setAuthCookie(HttpServletRequest request, HttpServletResponse response, AuthenticationContext context, String sessionKey, String tenantDomain) throws Fram

Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient resources

Sometimes you might see this WARN log continuously in DAS analyser nodes, This happened, the __spark_meta_table keeps some meta data info about the CAR files we deploy. When those information got corrupted, you can see this WARN log in console. "Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient resources" This is a known issue in spark and PR is already given to the spark. As a workaround we can remove the __spark_meta_table table and restart the node. Since the  __spark_meta_table table is encrypted, we just can't delete it from database, we have to use the Analytics data backup and restore tool