Wednesday, May 31, 2017

Understanding WSO2 ESB timeout configurations (ESB Story - 2)


When the message flowing through the ESB, It's having two main paths.
  • Message In sequence low (Client connection)
  • Message out sequence flow(back-end connection)

Aforementioned both flows having multiple timeout configurations and these configurations help to manage the connections properly in several situations. It is worth of know understand what are those timeout values and how it correctly configure to get reliable throughout form the WSO2 ESB.

To explain this story I am talking sample proxy service and how it going through the WSO2 ESB.

As I explained in my previous blog post (How WSO2 Enterprise Service Bus Works (ESB Story - 1), When the client application or the external client invoke the proxy service, That request message arrive to the Transport layer. From this point ESB engaged with four main point which are handle the connections.
  • Message listener (Http Listener)
  • Message Sender (Http Sender)
  • Endpoint timeout config
  • Global timeout config
[Please refer below diagram]






Message Listner/Sender Timeouts


When client sending message to the ESB Passthrough transport creating a connection. Same way another connection will be created from ESB to backend to sent request to the back end server. Timing out of either connection will be happen based on the the "http.socket.timeout" set in the passthru-http.properties file located at /repository/conf directory.

ex : http.socket.timeout=180000

Let say, client sent the request to the ESB and ESB sent again same to the backend. In that case back end talking long time to respond back. In such a case you will see source handler (which is in the request side) will get timeout as below. But it is expected to timeout ESB to backend connection (TargetHandler).

WARN {org.apache.synapse.transport.passthru.SourceHandler} - Connection time out after request is read: http-incoming-33855 {org.apache.synapse.transport.passthru.SourceHandler} 


Problem here is, both connection uses same timeout configuration. Once message received to the ESB from the external client SourceHandler timeout value will start counting and then message goest to the target handler. then only TargetHandler time out counter start. IIn such a case source handler will be timed out before TargetHandler timeout becase both are uses same timeout value. But the actual timeout value happens in the Targethandler side. This is most important situation when you are tracing down the timeout issues in ESB.

[Please refer previous blog post "How Messages are Flow Inside the WSO2 ESB (ESB Story - 3)" to understand SourceHandler and TargetHandler]

Endpoint timeout config


When the proxy service or the sequence having multiple endpoints, each endpoint can be set to separate timeout values. Once the timeout is reached, esb can trigger the fault sequence as a response action.Timeout value can be set as a "duration" parameter and fault sequence can be configure the "responseAction" parameter in endpoint configurations.




Tip :  Endpoint timeout value always need to be set to smaller value than the "http.socket.timeout" value configured in "passthru-http.properties" file

Global timeout config


Synapse which is the underlying mediation engine of WSO2 ESB is a complete asynchronous messaging engine which does not block its worker threads on network io. Instead of waiting the threads for responses, it registers a Calllback for a particular request and return. When the response is received, the registered callback is used to correlate it with the request and do the further processing. If the back end server not respond back, it is required to clear the registered Callbacks after sometime preventing possible memory leaks. It is done by a timer task called TimeoutHandler. ‘synapse.global_timeout_interval’ parameter represents the time duration which a Callback should be kept in the Callback store. If we have configured a timeout duration at the endpoint level, this global timeout value is not taken into consideration for that particular endpoint. For all the other endpoints which doesn’t have a timeout configuration, this global parameter value is considered as the timeout duration.

synapse.global_timeout_interval can be configured from the synapse.properties file. synapse.properties file is located at /repository/conf directory. Default value is 120 seconds.












Thursday, May 25, 2017

How WSO2 Enterprise Service Bus Works (ESB Story - 1)

WSO2 ESB is an open source integration solution which is built from the WSO2 CARBON platform. ESB is capable of supporting various transport types and do various kinds of message mediation according to the use case.
WSO2 ESB consist of set of major components which are allocated to specialized operation. Those are,
  • Transports layer

  • Message Builder/Formatter Layer

  • QOS Layer

  •  Mediation Engine

When a message sent to the ESB, ESB always uses SOAP message inside the ESB. Because of that, whatever the message come to the ESB, It will transport to the SOAP message. Below are the high-level way which message going through the ESB.
  • First, It is going through the transport layer which is handle the incoming transport.
  • Then It will move to the message builder engine to build the message.
  • There after, It will move to the QOS layer to do the QOS tasks to the message.
  • Then message will arrive to the mediation engine to do the specified inflow (in-sequence) mediation.
  • Finally, Message will sent out to the specified endpoint from the mediation engine.
Above message path we called as a "Request Path" and "Response Path" will be as follow.

  • Once response received from the endpoint, It will arrive to the mediation engine again and it will again do the mediation task which are configured in ESB out sequence.
  • After the mediation task done, Message will move to the QOS later again to the message to do the QOS again. 
  • There after, It will move to the message formatter to format the message again which are equal to the incoming message.
  • Finally it will move to the transport layer again and convert SOAP to specified transport which message was had in in-comming message.


This will give you a very basic idea how message go inside the ESB. But I will provide another post about detail explanation how above each layer works and what happen to the message which it is going though the each and every layer.

Tuesday, May 23, 2017

How Messages are Flow Inside the WSO2 ESB (ESB Story - 3)

WSO2 ESB is an open source middleware application which developed on top of the WSO2 carbon. ESB mainly underlying with Apache Axis2 and synapse.

If you are already ESB user, you know ESB received the message from external client or the user and of various transformation and send back to the separate endpoint or the back end. Then same way ESB, will get the response from endpoint or the backed and forward to the end user with transformation or without transformation. 

In this blog post I am trying to explain how the message flows inside the ESB specifically inside the mediation engine.

Mediation engine logics are written inside the Synapse-Core carbon component. Please find the Git location for checkout the code. I am specifically using ESB 5.0.0 for demonstrate this flow. Please note that ESB 5.0.0 uses synapse-core_2.1.7.wso2v7 version.

Message Flow
Message flow are separated to two main paths. 

1. Request path - In sequence flow
2. Response path - Out sequence flow


Request path - In sequence flow
In Axis2 level having "MessageReceiver" interface. Synapse core having implementation of "MessageReceiver" interface and it was implemented as a "SynapseMessageReceiver". This is the default message receiver which is configured in the Axis2. It will handle the incoming message through the synapse message mediation. 
If the ESB having proxy service, There is another implementation called "ProxyServiceMessageReceiver" do the same aforementioned task only for the proxy services. 

1. Once ESB received request to proxy service it will arrive to "receive" method.
 
org.apache.synapse.core.axis2.ProxyServiceMessageReceiver.receive()



2. When message comes to the Axis2 level it will create axis2 message context. But mediation engine uses different message context to do the mediation. Because of that, "MessageContextCreatorForAxis2" class will convert into synapse message context in "
org.apache.synapse.core.axis2.MessageContextCreatorForAxis2.getSynapseMessageContext()" method. This method will call via the "ProxyServiceMessageReceiver" class.



3. After create synapse message context, it will forward to the message mediation. Main sequence also considered as a one specific mediator.Therefore it will trigger the "mediate"method in "sequence mediator"class. 



org.apache.synapse.core.axis2.ProxyServiceMessageReceiver





org.apache.synapse.mediators.base.SequenceMediator.mediate()


4. Inside the "mediate" method in "org.apache.synapse.mediators.base.SequenceMediator" class, calls the "org.apache.synapse.mediators.AbstractListMediator.mediate()" method. 


org.apache.synapse.mediators.base.SequenceMediator



org.apache.synapse.mediators.AbstractListMediator

5. Inside the "AbstractListMediator" class will go through the entire mediation flow and verifies the content aware mediators are exists. 

6. Then it trigger the  "org.apache.synapse.endpoints.send()" method to send request to the endpoint.

7. Now it will be trigger the "org.apache.synapse.core.axis2.Axis2SynapseEnvironment.send()" method to send it from the the axis2 level.


8. After that it will send to "sendOn" method in "org.apache.synapse.core.axis2.Axis2Sender" class. Here, it will retrieve all handlers associate with that.

 9. After above task, "org.apache.synapse.core.axis2.Axis2Sender.sendOn()" method will be called. this is the class send message out from the ESB engine. 


10. Finally It will be send to the "org.apache.synapse.core.axis2.Axis2FlexibleMEPClient.send()" method.





Response path - Out sequence flow
 
11. Once message received from the endpoint, It will arrive to the "org.apache.synapse.core.axis2.SynapseCallbackReceiver.receive()" Method. 




12.Here, It reads all the information from the Message context and move forward to the "org.apache.synapse.mediators.base.SequenceMediator.mediate()" method as explained in aforementioned 3rd point. Out sequece also working as same way which is works in workflow.

13. After above, It will move to the "AbstractListMediator" as in above 4th point and then it will trigger the "org.apache.axis2.engine.AxisEngine.receive()" method.



I hope this will give you the brief idea how the message mediation happen inside the WSO2 ESB.






Friday, May 19, 2017

How to view Admin Services given WSO2 product

WSO2 products are uses SOAP services to communicate internally in-between UI and the back end. Sometime you may want to do direct invocation on particular admin service to do several task.

As a example if you want to add new users without using admin service, It can be achived by invoking the UserManagementAdminServie. Likewise you can use inbuilt admin services to do such kind of operations.

Some people does not know what are the admin services available in running WSO2 instance. Please find the easiest way to find the admin services and it's endpoints.

I am using WSO2 API Manager.

1. Please download WSO2 API Manager from above location.
2. Start API Manager with following property.
    Ex : wso2server.sh -DosgiConsole 

You will notice server is starting as below

Chamaras-MacBook-Pro:wso2am-2.0.0 chamara$ ./bin/wso2server.sh -DosgiConsole
JAVA_HOME environment variable is set to /Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home
CARBON_HOME environment variable is set to /Users/chamara/wso2/products/apim/wso2am-2.0.0
Using Java memory options: -Xms256m -Xmx1024m
OSGi console has been enabled with options: -console



3. By pressing "Enter" in terminal (after start server) you will landed to the OSGI console.


4. Now add below command and it will show all the admin services available in server.
"listAdminServices"