Skip to main content

How to recover from WSO2 Carbon server not starting state

This blog post describes the steps you can follow in a situation where you have saved all your configurations in the embedded registry of your WSO2 Carbon server and suddenly the server is not starting due to some changes in the back end services and that changes has a direct impact on your configuration.

Let's say WSO2 ESB server is not starting due to some changes in the security policies which has applied in the WSDL files you are using in your proxy configurations. In this kind of a scenario, that particular proxy service will not be able start when the server starts. In the latest ESBs (WSO2 ESB 4.5.X onwards) server will start in failSafe mode by ignoring the failure of artifacts. But in older versions (ESB 1.x.x to 3.x.x) this feature is not available and the server will not start.

In this kind of scenario, you can't change your proxy configurations since you have saved them in the internal registry (which will save those data in internal H2 database).


Here is the steps you need to follow for changing artifacts in a scenario like this. You need to download compatible Governance Registry version for doing this.

You can follow this link to find out the corresponding GREG version.
http://wso2.com/products/carbon/release-matrix/

As an example, let's say you have ESB 2.1.3 installed in your system. From the above table you can find the Carbon version for that product is 2.0.3 and the corresponding GREG version is 3.0.3.

Please download GREG from the following link.
http://wso2.com/more-downloads/governance-registry (make sure you download the correct version)

1. First, make a backup of your system.

2. Copy the contents of ESB_HOME/database folder to GREG_HOME/database folder.

3. Change the carbon.xml file of GREG_HOME/conf such that you can view the H2 database viewer of the database as mentioned below.

    <H2DatabaseConfiguration>
        <property name="web" />
        <property name="webPort">8083</property>
        <property name="webAllowOthers" />
        <!--property name="webSSL" />
        <property name="tcp" />
        <property name="tcpPort">9092</property>
        <property name="tcpAllowOthers" />
        <property name="tcpSSL" />
        <property name="pg" />
        <property name="pgPort">5435</property>
        <property name="pgAllowOthers" />
        <property name="trace" />
        <property name="baseDir">${carbon.home}</property-->
    </H2DatabaseConfiguration>

4. Also change the management console ports of the GREG by editing following lines in GREG_HOME/conf/transports.xml file.
 <transport name="http" class="org.wso2.carbon.server.transports.http.HttpTransport">
        <parameter name="port">9764</parameter>

    <transport name="https" class="org.wso2.carbon.server.transports.http.HttpsTransport">
        <parameter name="port">9444</parameter>

5. Now start the GREG by executing sh wso2server.sh command inside GREG_HOME/bin folder.

6. Create a folder called esb-artifacts inside GREG_HOME\bin directory and change the directory to that.

7. Checkout "/" from registry to this folder by executing following command within esb-artifacts folder.

sh ../checkin-client.sh co https://localhost:9444/registry/ -u admin -p admin

8. Now you can see all the configurations saved in the registry are fetched in to current folder.

9. Fix the proxy service which can be found in esb-artifacts/carbon/synapse-config/proxy-services folder.

10.Now check in the changes in to registry by executing the following command.

sh ../checkin-client.sh ci https://localhost:9444/registry/ -u admin -p admin

11. Browse H2 DBs REG_RESOURCES table and find the REG_CONTENT_ID for the proxy service which you have changed. Now find the content of that proxy service by selecting the REG_CONTENT_ID from REG_CONTENT table and find blob.
(You can access the H2 browser by http://localhost:8083 and login to the database with following parameters)
JDBC URL = jdbc:h2:GREG_HOME/database/WSO2CARBON_DB
username = wso2carbon
password = wso2carbon

12. Start the ESB with enabling H2 browser as mentioned in the Step 3 with a different port number (ex:8082).

13. Browse ESBs H2 DBs REG_RESOURCES table and find the REG_CONTENT_ID for the proxy service which you need to change. Now find the content of that proxy service by selecting the REG_CONTENT_ID from REG_CONTENT table and find blob.
(You can access the H2 browser by http://localhost:8083 and login to the database with following parameters)
JDBC URL = jdbc:h2:ESB_HOME/database/WSO2CARBON_DB
username = wso2carbon
password = wso2carbon

14. Copy BLOB content of the GREG in to same REG_RESOURCE in the ESB

15. Save (commit) the database change and restart the ESB.

now you can reflect the changes done in greg from the ESB itself. With the above method you can change the required configurations and save them in ESB registry and then restart the ESB successfully.
Labels:

Comments

Post a Comment

Popular posts from this blog

WSO2 ESB tuning performance with threads

I have written several blog posts explaining the internal behavior of the ESB and the threads created inside ESB. With this post, I am talking about the effect of threads in the WSO2 ESB and how to tune up threads for optimal performance. You can refer [1] and [2] to understand the threads created within the ESB. [1] http://soatutorials.blogspot.com/2015/05/understanding-threads-created-in-wso2.html [2] http://wso2.com/library/articles/2012/03/importance-performance-wso2-esb-handles-nonobvious/ Within this blog post, I am discussing about the "worker threads" which are used for processing the data within the WSO2 ESB. There are 2 types of worker threads created when you start sending the requests to the server 1) Server Worker/Client Worker Threads 2) Mediator Worker (Synapse-Worker) Threads Server Worker/Client Worker Threads These set of threads will be used to process all the requests/responses coming to the ESB server. ServerWorker Threads will be used to pr
4 comments
Read more

How puppet works in your IT infrstructure

What is Puppet? Puppet is IT automation software that helps system administrators manage infrastructure throughout its lifecycle, from provisioning and configuration to orchestration and reporting. Using Puppet, you can easily automate repetitive tasks, quickly deploy critical applications, and proactively manage change, scaling from 10s of servers to 1000s, on-premise or in the cloud. How the puppet works? It works like this..Puppet agent is a daemon that runs on all the client servers(the servers where you require some configuration, or the servers which are going to be managed using puppet.) All the clients which are to be managed will have puppet agent installed on them, and are called nodes in puppet. Puppet Master: This machine contains all the configuration for different hosts. Puppet master will run as a daemon on this master server. Puppet Agent: This is the daemon that will run on all the servers, which are to be managed using p
7 comments
Read more

How to configure timeouts in WSO2 ESB to get rid of client timeout errors

WSO2 ESB has defined some configuration parameters which controls the timeout of a particular request which is going out of ESB. In a particular  scneario, your client sends a request to ESB, and then ESB sends a request to another endpoint to serve the request. CLIENT->WSO2 ESB->BACKEND The reason for clients getting timeout is that ESB timeout is larger than client's timeout. This can be solved by either increasing the timeout at client side or by decreasing the timeout in ESB side. In any of the case, you can control the timeout in ESB using the below properties. 1) Global timeout defined in synapse.properties (ESB_HOME\repository\conf\) file. This will decide the maximum time that a callback is waiting in the ESB for a response for a particular request. If ESB does not get any response from Back End, it will drop the message and clears out the call back. This is a global level parameter which affects all the endpoints configured in ESB. synapse.global_timeout_inte
3 comments
Read more