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

How to protect your APIs with self contained access token (JWT) using WSO2 API Manager and WSO2 Identity Server

In a typical enterprise information system, there is a high chance that people will use different types of systems built by different vendors to implement certain types of functionalities. The APIs might be hosted in an API Manager developed by vendor A and the user management can be implemented using a different vendor (vendor B). In this type of a situation, one system will not be able to directly contact the other system but they want to use both systems in tandem. Self-contained access tokens are used in these types of situations where applications can get the token from one system and use that in another system to access protected resources. In this scenario, the second system does not need to make a contact to the first system over the network to validate the user information since the token is self-contained and it has relevant details about the user. This will improve the token processing time significantly since it completely removes the network interaction. The below fig...
1 comment
Read more

WSO2 ESB creating a response for a "GET" request

When you are creating REST APIs with WSO2 ESB, you may need to send some response message back to the user when something goes wrong. In this kind of scenario, you can create a payload inside the ESB and send it back. For doing this, you can use the below configuration. <api xmlns=" http://ws.apache.org/ ns/synapse " name="LoopBackProxy" context="/loopback">    <resource methods="POST GET">       <inSequence>          <property name="NO_ENTITY_BODY" scope="axis2" action="remove"></property>          <log level="full"></log>          <payloadFactory media-type="xml">             <format>                <m:messageBeforeLoopBack xmlns:m=" http://services...
Post a Comment
Read more

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...
9 comments
Read more