diff --git a/modules/distribution/src/analytics/conf/log4j.properties b/modules/distribution/src/analytics/conf/log4j.properties
index a7ba02bc..8424bc6e 100644
--- a/modules/distribution/src/analytics/conf/log4j.properties
+++ b/modules/distribution/src/analytics/conf/log4j.properties
@@ -86,6 +86,9 @@ log4j.logger.org.spark-project=WARN
 log4j.logger.akka=WARN
 log4j.logger.org.apache.spark.util.ClosureCleaner=ERROR
 
+# uncomment the following logs to see http calls headers and messages
+#log4j.logger.feign=DEBUG
+
 log4j.additivity.org.apache.axis2.clustering=false
 log4j.additivity.com.atomikos=false
 log4j.additivity.org.apache=false
diff --git a/modules/distribution/src/assembly/filter.properties b/modules/distribution/src/assembly/filter.properties
index aeefa12d..e27e6d46 100644
--- a/modules/distribution/src/assembly/filter.properties
+++ b/modules/distribution/src/assembly/filter.properties
@@ -21,7 +21,7 @@ product.key=IoT
 product.version=3.1.0-SNAPSHOT
 product.doc.version=310
 
-carbon.version=4.4.14
+carbon.version=4.4.16
 default.server.role=IoTServer
 cep.server.role=ComplexEventProcessor
 das.server.role=DataAnalyticsServer
diff --git a/modules/distribution/src/broker/conf/broker.xml b/modules/distribution/src/broker/conf/broker.xml
index 9e525b7b..b7be838a 100755
--- a/modules/distribution/src/broker/conf/broker.xml
+++ b/modules/distribution/src/broker/conf/broker.xml
@@ -27,560 +27,573 @@ expression of the property.
 This file is ciphertool compliant. Refer PRODUCT_HOME/repository/conf/security/cipher-text.properties for examples.-->
 <broker>
 
-    <coordination>
-        <!-- You can override the cluster node identifier of this MB node using the nodeID. 
-        If it is left as "default", the default node ID will be generated for it. (Using IP + UUID).
-        The node ID of each member should ALWAYS be unique.-->
-        <nodeID>default</nodeID>
-        <!-- Thrift is used to maintain and sync slot (message groups) ranges between MB nodes. -->
-        <thriftServerHost>localhost</thriftServerHost>
-        <thriftServerPort>7611</thriftServerPort>
-        <thriftSOTimeout>0</thriftSOTimeout>
-        <!--Thrift server reconnect timeout. Value specified in SECONDS-->
-        <thriftServerReconnectTimeout>5</thriftServerReconnectTimeout>
-        <!-- Hazelcast reliable topics are used to share all notifications across the MB cluster (e.g. subscription
-        changes), And this property defines the time-to-live for a notification since its creation. (in Seconds) -->
-        <clusterNotificationTimeout>10</clusterNotificationTimeout>
-
-        <!-- Configurations related RDBMS based coordination algorithm -->
-        <rdbmsBasedCoordination enabled="false">
-            <!-- Heartbeat interval used in the RDBMS base coordination algorithm in milliseconds -->
-            <heartbeatInterval>5000</heartbeatInterval>
-
-            <!-- Time to wait before informing others about coordinator change in milliseconds. This value should be
-            larger than a database read time including network latency and should be less than heartbeatInterval -->
-            <coordinatorEntryCreationWaitTime>3000</coordinatorEntryCreationWaitTime>
-
-            <!-- Time interval used to poll database for membership related events in milliseconds. -->
-            <eventPollingInterval>4000</eventPollingInterval>
-        </rdbmsBasedCoordination>
-
-        <!-- Enabling this will make the cluster notifications such as Queue changes(additions and deletions),
-        Subscription changes, etc. sent within the cluster be synchronized using RDBMS. If set to false, Hazelcast
-        will be used for this purpose.-->
-        <RDBMSBasedClusterEventSynchronization enabled="false">
-
-            <!--Specifies the interval at which, the cluster events will be read from the database. Needs to be
-            declared in milliseconds. Setting this to a very low value could downgrade the performance where as
-            setting this to a large value could increase the time taken for a cluster event to be synchronized in
-            all the nodes in a cluster.-->
-            <eventSyncInterval>1000</eventSyncInterval>
-
-        </RDBMSBasedClusterEventSynchronization>
-    </coordination>
-
-    <!-- You can enable/disable specific messaging transports in this section. By default all 
-    transports are enabled. This section also allows you to customize the messaging flows used 
-    within WSO2 MB. NOT performance related, but logic related. -->
-    <transports>
-        <amqp enabled="true">
-            <bindAddress>0.0.0.0</bindAddress>
-
-            <defaultConnection enabled="true" port="5672" />
-
-            <sslConnection enabled="true" port="8672">
-                <keyStore>
-                     <location>repository/resources/security/wso2carbon.jks</location>
-                     <password>wso2carbon</password>
-                     <certType>SunX509</certType>
-                </keyStore>
-                <trustStore>
-                    <location>repository/resources/security/client-truststore.jks</location>
-                    <password>wso2carbon</password>
-                    <certType>SunX509</certType>
-                </trustStore>
-            </sslConnection>
-
-            <maximumRedeliveryAttempts>10</maximumRedeliveryAttempts>
-            <allowSharedTopicSubscriptions>false</allowSharedTopicSubscriptions>
-            <allowStrictNameValidation>true</allowStrictNameValidation>
-
-            <!-- Refer conf/advanced/qpid-config.xml for further AMQP-specific configurations.-->
-        </amqp>
-        <mqtt enabled="true">
-            <bindAddress>0.0.0.0</bindAddress>
-
-            <defaultConnection enabled="true" port="1883" />
-
-            <sslConnection enabled="true" port="8883">
-                <keyStore>
-                    <location>repository/resources/security/wso2carbon.jks</location>
-                    <password>wso2carbon</password>
-                    <certType>SunX509</certType>
-                </keyStore>
-                <trustStore>
-                    <location>repository/resources/security/client-truststore.jks</location>
-                    <password>wso2carbon</password>
-                    <certType>SunX509</certType>
-                </trustStore>
-            </sslConnection>
-
-            <!--All receiving events/messages will be in this ring buffer. Ring buffer size
-            of MQTT inbound event disruptor. Default is set to 32768 (1024 * 32)
-            Having a large ring buffer wi
-            ll have a increase memory usage and will improve performance
-            and vise versa -->
-            <inboundBufferSize>32768</inboundBufferSize>
-
-            <!-- Messages delivered to clients will be placed in this ring buffer. 
-            Ring buffer size of MQTT delivery event disruptor. Default is set to 32768 (1024 * 32)
-            Having a large ring buffer will have a increase memory usage and will improve performance
-            and vise versa -->
-            <deliveryBufferSize>32768</deliveryBufferSize>
-            
-
-            <security>
-                   <!--
-                       Instructs the MQTT server whether clients should always send credentials
-                       when establishing a connection.
-                       Possible values:
-                        OPTIONAL: This is the default value. MQTT clients may or may not send 
-                                  credentials. If a client sends credentials server will 
-                                  validates it. 
-                                  If client doesn't send credentials then server will not 
-                                  authenticate, but allows client to establish the connection. 
-                                  This behavior adheres to MQTT 3.1 specification.
-                        REQUIRED: Clients should always provide credentials when connecting. 
-                                  If client doesn't send credentials or they are invalid 
-                                  server rejects the connection.
-                   -->
-                   <authentication>REQUIRED</authentication>
-                  
-                   <!--Class name of the authenticator to use. class should 
-                       inherit from org.dna.mqtt.moquette.server.IAuthenticator
-                       Note: default implementation authenticates against carbon user store
-                       based on supplied username/password
-                   -->
-                    <authenticator class="org.wso2.carbon.andes.authentication.andes.OAuth2BasedMQTTAuthenticator">
-                        <property name="hostURL">https://localhost:9443/services/OAuth2TokenValidationService</property>
-                        <property name="username">admin</property>
-                        <property name="password">admin</property>
-                        <property name="maxConnectionsPerHost">10</property>
-                        <property name="maxTotalConnections">150</property>
-                    </authenticator>
-
-                    <!--
-                       Instructs the MQTT server whether clients should be authorized before either publishing or subscribing
-                       Possible values:
-                        NOT_REQUIRED: This is the default value. MQTT clients will skip the authorization check
-                        REQUIRED: Clients will authorized before publishing. this will execute the class given in authorzier
-                        Note: authentication should be REQUIRED for authorization to be REQUIRED.
-                   -->
-                    <authorization>REQUIRED</authorization>
-
-                    <!--Class name of the authorizer to use. class should
-                        inherit from org.dna.mqtt.moquette.server.IAutherizer
-                        Note: default implementation authorizes against carbon permission with the topic.
-                    -->
-                    <!--connectionPermission is required for a user to connect to broker
-                    subscriberPermission is needed to subscribe(subriber permission can be more than one)
-                    publisherPermission is needed to publish(publisher permission can be more than one)
-                    -->
-                    <authorizer class="org.wso2.carbon.andes.extensions.device.mgt.mqtt.authorization.DeviceAccessBasedMQTTAuthorizer">
-						<!--<property name="connectionPermission">/permission/admin/device-mgt/user</property>-->
-                        <!--topic subscription permissions which are assigned through grouping-->
-                        <property name="subscriberPermission">/permission/device-mgt/user/groups/device_events</property>
-                        <!--topic publisher permissions which are assigned through grouping-->
-                        <property name="publisherPermission">/permission/device-mgt/user/groups/device_operation</property>
-
-                        <property name="username">admin</property>
-                        <property name="password">admin</property>
-                        <property name="tokenEndpoint">https://localhost:8243</property>
-                        <!--offset time from expiry time to trigger refresh call - seconds -->
-                        <property name="tokenRefreshTimeOffset">100</property>
-                        <property name="deviceMgtServerUrl">https://localhost:8243</property>
-                    </authorizer>
-            </security>
-        </mqtt>
-
-    </transports>
-
-    <!-- Depending on the database type selected in master-datasources.xml, you must enable the
-    relevant Data access classes here. Currently WSO2 MB Supports RDBMS(any RDBMS store). 
+	<coordination>
+		<!-- You can override the cluster node identifier of this MB node using the nodeID.
+		If it is left as "default", the default node ID will be generated for it. (Using IP + UUID).
+		The node ID of each member should ALWAYS be unique.-->
+		<nodeID>default</nodeID>
+		<!-- Thrift is used to maintain and sync slot (message groups) ranges between MB nodes. -->
+		<thriftServerHost>localhost</thriftServerHost>
+		<thriftServerPort>7611</thriftServerPort>
+		<thriftSOTimeout>0</thriftSOTimeout>
+		<!--Thrift server reconnect timeout. Value specified in SECONDS-->
+		<thriftServerReconnectTimeout>5</thriftServerReconnectTimeout>
+		<!-- Hazelcast reliable topics are used to share all notifications across the MB cluster (e.g. subscription
+		changes), And this property defines the time-to-live for a notification since its creation. (in Seconds) -->
+		<clusterNotificationTimeout>10</clusterNotificationTimeout>
+
+		<!-- Configurations related RDBMS based coordination algorithm -->
+		<rdbmsBasedCoordination enabled="true">
+			<!-- Heartbeat interval used in the RDBMS base coordination algorithm in milliseconds -->
+			<heartbeatInterval>5000</heartbeatInterval>
+
+			<!-- Time to wait before informing others about coordinator change in milliseconds. This value should be
+			larger than a database read time including network latency and should be less than heartbeatInterval -->
+			<coordinatorEntryCreationWaitTime>3000</coordinatorEntryCreationWaitTime>
+
+			<!-- Time interval used to poll database for membership related events in milliseconds. -->
+			<eventPollingInterval>4000</eventPollingInterval>
+		</rdbmsBasedCoordination>
+
+		<!-- Enabling this will make the cluster notifications such as Queue changes(additions and deletions),
+		Subscription changes, etc. sent within the cluster be synchronized using RDBMS. If set to false, Hazelcast
+		will be used for this purpose.-->
+		<rdbmsBasedClusterEventSynchronization enabled="true">
+
+			<!--Specifies the interval at which, the cluster events will be read from the database. Needs to be
+			declared in milliseconds. Setting this to a very low value could downgrade the performance where as
+			setting this to a large value could increase the time taken for a cluster event to be synchronized in
+			all the nodes in a cluster.-->
+			<eventSyncInterval>1000</eventSyncInterval>
+
+		</rdbmsBasedClusterEventSynchronization>
+	</coordination>
+
+	<!-- You can enable/disable specific messaging transports in this section. By default all
+	transports are enabled. This section also allows you to customize the messaging flows used
+	within WSO2 MB. NOT performance related, but logic related. -->
+	<transports>
+		<amqp enabled="true">
+			<bindAddress>0.0.0.0</bindAddress>
+
+			<defaultConnection enabled="true" port="5672" />
+
+			<sslConnection enabled="true" port="8672">
+				<keyStore>
+					<location>repository/resources/security/wso2carbon.jks</location>
+					<password>wso2carbon</password>
+					<certType>SunX509</certType>
+				</keyStore>
+				<trustStore>
+					<location>repository/resources/security/client-truststore.jks</location>
+					<password>wso2carbon</password>
+					<certType>SunX509</certType>
+				</trustStore>
+			</sslConnection>
+
+			<maximumRedeliveryAttempts>10</maximumRedeliveryAttempts>
+			<allowSharedTopicSubscriptions>false</allowSharedTopicSubscriptions>
+			<allowStrictNameValidation>true</allowStrictNameValidation>
+
+			<!-- Refer repository/conf/advanced/qpid-config.xml for further AMQP-specific configurations.-->
+		</amqp>
+		<mqtt enabled="true">
+			<bindAddress>0.0.0.0</bindAddress>
+
+			<defaultConnection enabled="true" port="1883" />
+
+			<sslConnection enabled="true" port="8883">
+				<keyStore>
+					<location>repository/resources/security/wso2carbon.jks</location>
+					<password>wso2carbon</password>
+					<certType>SunX509</certType>
+				</keyStore>
+				<trustStore>
+					<location>repository/resources/security/client-truststore.jks</location>
+					<password>wso2carbon</password>
+					<certType>SunX509</certType>
+				</trustStore>
+			</sslConnection>
+
+			<!--All receiving events/messages will be in this ring buffer. Ring buffer size
+			of MQTT inbound event disruptor. Default is set to 32768 (1024 * 32)
+			Having a large ring buffer will have a increase memory usage and will improve performance
+			and vise versa -->
+			<inboundBufferSize>32768</inboundBufferSize>
+
+			<!-- Messages delivered to clients will be placed in this ring buffer.
+			Ring buffer size of MQTT delivery event disruptor. Default is set to 32768 (1024 * 32)
+			Having a large ring buffer will have a increase memory usage and will improve performance
+			and vise versa -->
+			<deliveryBufferSize>32768</deliveryBufferSize>
+
+
+			<security>
+				<!--
+					   Instructs the MQTT server whether clients should always send credentials
+					   when establishing a connection.
+					   Possible values:
+						OPTIONAL: This is the default value. MQTT clients may or may not send
+								  credentials. If a client sends credentials server will
+								  validates it.
+								  If client doesn't send credentials then server will not
+								  authenticate, but allows client to establish the connection.
+								  This behavior adheres to MQTT 3.1 specification.
+						REQUIRED: Clients should always provide credentials when connecting.
+								  If client doesn't send credentials or they are invalid
+								  server rejects the connection.
+				   -->
+				<authentication>REQUIRED</authentication>
+
+				<!--Class name of the authenticator to use. class should
+					   inherit from org.dna.mqtt.moquette.server.IAuthenticator
+					   Note: default implementation authenticates against carbon user store
+					   based on supplied username/password
+				   -->
+				<authenticator class="org.wso2.carbon.andes.authentication.andes.OAuth2BasedMQTTAuthenticator">
+					<property name="hostURL">https://localhost:9443/services/OAuth2TokenValidationService</property>
+					<property name="username">admin</property>
+					<property name="password">admin</property>
+					<property name="maxConnectionsPerHost">10</property>
+					<property name="maxTotalConnections">150</property>
+				</authenticator>
+
+				<!--
+				   Instructs the MQTT server whether clients should be authorized before either publishing or subscribing
+				   Possible values:
+					NOT_REQUIRED: This is the default value. MQTT clients will skip the authorization check
+					REQUIRED: Clients will authorized before publishing. this will execute the class given in authorzier
+					Note: authentication should be REQUIRED for authorization to be REQUIRED.
+			   -->
+				<authorization>REQUIRED</authorization>
+
+				<!--Class name of the authorizer to use. class should
+					inherit from org.dna.mqtt.moquette.server.IAutherizer
+					Note: default implementation authorizes against carbon permission with the topic.
+				-->
+				<!--connectionPermission is required for a user to connect to broker
+				subscriberPermission is needed to subscribe(subriber permission can be more than one)
+				publisherPermission is needed to publish(publisher permission can be more than one)
+				-->
+				<authorizer class="org.wso2.carbon.andes.extensions.device.mgt.mqtt.authorization.DeviceAccessBasedMQTTAuthorizer">
+					<!--<property name="connectionPermission">/permission/admin/device-mgt/user</property>-->
+					<!--topic subscription permissions which are assigned through grouping-->
+					<property name="subscriberPermission">/permission/device-mgt/user/groups/device_events</property>
+					<!--topic publisher permissions which are assigned through grouping-->
+					<property name="publisherPermission">/permission/device-mgt/user/groups/device_operation</property>
+
+					<property name="username">admin</property>
+					<property name="password">admin</property>
+					<property name="tokenEndpoint">https://localhost:8243</property>
+					<!--offset time from expiry time to trigger refresh call - seconds -->
+					<property name="tokenRefreshTimeOffset">100</property>
+					<property name="deviceMgtServerUrl">https://localhost:8243</property>
+				</authorizer>
+			</security>
+		</mqtt>
+
+	</transports>
+
+	<!-- Depending on the database type selected in master-datasources.xml, you must enable the
+	relevant Data access classes here. Currently WSO2 MB Supports RDBMS(any RDBMS store).
 	These stores are accessed for two purposes.
-	
-    1. For message persistence ("messageStore")
-    2. To persist and access other information relevant to messaging protocols.("contextStore").-->
-
-    <!-- By default WSO2 MB runs with H2 persistent store. If you plan to use a different
-    store, point to the relevant dataSource or uncomment the database appropriately.
-
-    RDBMS
-    =====
-    If you are running an RDBMS you can use the existing RDBMS implementation of stores
-    by pointing to the correct data source by updating the property "dataSource".
-
-    Data source entry should be present in
-    <MB_HOME>/conf/datasources/master-datasources.xml.
-
-    -->
-    <persistence>
-
-        <!-- RDBMS MB Store Configuration -->
-
-        <messageStore class="org.wso2.andes.store.rdbms.RDBMSMessageStoreImpl">
-            <property name="dataSource">WSO2MBStoreDB</property>
-            <property name="storeUnavailableSQLStateClasses">08</property>
-            <property name="integrityViolationSQLStateClasses">23,27,44</property>
-            <property name="dataErrorSQLStateClasses">21,22</property>
-            <property name="transactionRollbackSQLStateClasses">40</property>
-        </messageStore>
-
-        <contextStore class="org.wso2.andes.store.rdbms.RDBMSAndesContextStoreImpl">
-            <property name="dataSource">WSO2MBStoreDB</property>
-            <property name="storeUnavailableSQLStateClasses">08</property>
-            <property name="integrityViolationSQLStateClasses">23,27,44</property>
-            <property name="dataErrorSQLStateClasses">21,22</property>
-            <property name="transactionRollbackSQLStateClasses">40</property>
-        </contextStore>
-
-        <cache>
-            <!-- Size of the messages cache in MBs. Setting '0' will disable the cache. -->
-            <size>256</size>
-            <!-- Expected concurrency for the cache (4 is guava default) -->					
-            <concurrencyLevel>4</concurrencyLevel>
-            <!--Number of seconds cache will keep messages after they are 
-                              added (unless they are consumed and deleted).-->					
-            <expirySeconds>2</expirySeconds>
-
-            <!--Reference type used to hold messages in memory.
-                    weak   - Using java weak references ( - results higher cache misses)
-                    strong - ordinary references ( - higher cache hits, but not good if server 
-                             is going to run with limited heap size + under severe load).
-            -->
-            <valueReferenceType>strong</valueReferenceType>
-
-            <!--Prints cache statistics in 2 minute intervals 
-                                                   in carbon log ( and console)-->					
-            <printStats>false</printStats>
-        </cache>
-
-        <!-- This class decides how unique IDs are generated for the MB node. This id generator is
-        expected to be thread safe and a implementation of interface
-        org.wso2.andes.server.cluster.coordination.MessageIdGenerator
-
-        NOTE: This is NOT used in MB to generate message IDs. -->
-        <idGenerator>org.wso2.andes.server.cluster.coordination.TimeStampBasedMessageIdGenerator</idGenerator>
-
-        <!-- This is the Task interval (in SECONDS) to check whether communication 
-        is healthy between message store (/Database) and this server instance. -->
-        <storeHealthCheckInterval>10</storeHealthCheckInterval>
-    </persistence>
-
-    <!--Publisher transaction related configurations.-->
-    <transaction>
-
-        <!--Maximum batch size (Messages) for a transaction. Exceeding this limit will result
-        in a failure in the subsequent commit request. Default is set to 10MB. Limit is
-        calculated considering the payload of messages-->
-        <maxBatchSizeInBytes>10000000</maxBatchSizeInBytes>
-    </transaction>
-
-    <!-- This section allows you to tweak memory and processor allocations used by WSO2 MB.
-    Broken down by critical processes so you have a clear view of which parameters to change in
-    different scenarios.  -->
-    <performanceTuning>
-
-        <slots>
-            <!--
-                If message publishers are slow, time taken to fill the slot (up to <windowSize>) will be longer.
-                This will add an latency to messages. Therefore broker will mark the slot as 
-                ready to deliver before even the slot is entirely filled after specified time.
-                NOTE: specified in milliseconds.
-            -->
-            <messageAccumulationTimeout>2000</messageAccumulationTimeout>
-
-            <!--Rough estimate for size of a slot-->
-            <windowSize>1000</windowSize>
-
-            <!-- Time interval which broker check for slots that can be marked as 'ready to deliver' 
-                 (- slots which have a aged more than 'messageAccumulationTimeout')
-                 NOTE: specified in milliseconds.
-            -->
-            <timerPeriod>1000</timerPeriod>
-
-            <!--Number of SlotDeliveryWorker threads that should be started-->
-            <workerThreadCount>5</workerThreadCount>
-
-        </slots>
-
-        <delivery>
-            <!-- Maximum number of undelivered messages that can have in memory. Increasing this
-            value increase the possibility of out of memory scenario but performance will be
-            improved -->
-            <maxNumberOfReadButUndeliveredMessages>1000</maxNumberOfReadButUndeliveredMessages>
-
-            <!-- This is the ring buffer size of the delivery disruptor. This value should be a
-            power of 2 (E.g. 1024, 2048, 4096). Use a small ring size if you want to reduce the
-            memory usage. -->
-            <ringBufferSize>4096</ringBufferSize>
-
-            <!--Number of parallel readers used to used to read content from message store.
-            Increasing this value will speed-up the message sending mechanism. But the load
-            on the data store will increase. -->
-            <parallelContentReaders>5</parallelContentReaders>
-
-            <!-- Number of parallel decompression handlers used to decompress messages before send to subscribers.
-            Increasing this value will speed-up the message decompressing mechanism. But the system load
-            will increase. -->
-            <parallelDecompressionHandlers>5</parallelDecompressionHandlers>
-
-            <!-- Number of parallel delivery handlers used to send messages to subscribers.
-            Increasing this value will speed-up the message sending mechanism. But the system load
-            will increase. -->
-            <parallelDeliveryHandlers>5</parallelDeliveryHandlers>
-
-            <!-- The size of the batch represents, at a given time the number of messages that could 
-            be retrieved from the database. -->
-            <contentReadBatchSize>65000</contentReadBatchSize>
-
-            <contentCache>
-                <!-- Specify the maximum number of entries the cache may contain. -->
-                <maximumSize>100</maximumSize>
-                <!-- Specify the time in seconds that each entry should be 
-                     automatically removed from the cache after the entry's creation. -->
-                <expiryTime>120</expiryTime>
-            </contentCache>
-
-            <!--When delivering topic messages to multiple topic 
-                subscribers one of following stratigies can be choosen.
-            
-               1. DISCARD_NONE     - Broker do not loose any message to any subscriber. 
-                                     When there are slow subscribers this can cause broker 
-                                     go Out of Memory.
-
-               2. SLOWEST_SUB_RATE - Broker deliver to the speed of the slowest
-                                     topic subscriber. This can cause fast subscribers
-                                     to starve. But eliminate Out of Memory issue.
-
-               3. DISCARD_ALLOWED  - Broker will try best to deliver. To eliminate Out
-                                     of Memory threat broker limits sent but not acked message 
-                                     count to <maxUnackedMessages>. 
-                                     If it is breached, and <deliveryTimeout> is also 
-                                     breached message can either be lost or actually 
-                                     sent but ack is not honoured.
-            -->
-            <topicMessageDeliveryStrategy>
-                <strategyName>DISCARD_NONE</strategyName>
-                <!-- If you choose DISCARD_ALLOWED topic message delivery strategy, 
-                     broker keep messages in memory until ack is done until this timeout.
-                     If an ack is not received under this timeout, ack will be simulated 
-                     internally and real acknowledgement is discarded.
-                     deliveryTimeout is in seconds -->
-                <deliveryTimeout>60</deliveryTimeout>
-            </topicMessageDeliveryStrategy>
-        </delivery>
-
-        <ackHandling>
-            <!--Number of message acknowledgement handlers to process acknowledgements concurrently.
-            These acknowledgement handlers will batch and process acknowledgements.  -->
-            <ackHandlerCount>1</ackHandlerCount>
-
-            <!--Maximum batch size of the acknowledgement handler. Andes process acknowledgements in
-            batches using Disruptor Increasing the batch size reduces the number of calls made to
-            database by MB. Depending on the database optimal batch size this value should be set.
-            Batches will be of the maximum batch size mostly in high throughput scenarios.
-            Underlying implementation use Disruptor for batching hence will batch message at a
-            lesser value than this in low throughput scenarios -->
-            <ackHandlerBatchSize>100</ackHandlerBatchSize>
-
-            <!-- Message delivery from server to the client will be paused temporarily if number of
-            delivered but unacknowledged message count reaches this size. Should be set considering
-            message consume rate. This is to avoid overwhelming slow subscribers. -->
-            <maxUnackedMessages>1000</maxUnackedMessages>
-        </ackHandling>
-
-        <contentHandling>
-
-            <!-- Within Andes there are content chunk handlers which convert incoming large content
-            chunks into max content chunk size allowed by Andes core. These handlers run in parallel
-            converting large content chunks to smaller chunks.
-
-            If the protocol specific content chunk size is different from the max chunk size allowed
-            by Andes core and there are significant number of large messages published, then having
-            multiple handlers will increase performance. -->
-            <contentChunkHandlerCount>3</contentChunkHandlerCount>
-
-            <!-- Andes core will store message content chunks according to this chunk size. Different
-            database will have limits and performance gains by tuning this parameter.
-
-            For instance in MySQL the maximum table column size for content is less than 65534, which
-            is the default chunk size of AMQP. By changing this parameter to a lesser value we can
-            store large content chunks converted to smaller content chunks within the DB with this
-            parameter. -->
-            <maxContentChunkSize>65500</maxContentChunkSize>
-
-            <!-- This is the configuration to allow compression of message contents, before store messages
-            into the database.-->
-            <allowCompression>false</allowCompression>
-
-            <!-- This is the configuration to change the value of the content compression threshold (in bytes).
-            Message contents less than this value will not compress, even compression is enabled. The recommended
-            message size of the smallest message before compression is 13bytes. Compress messages smaller than
-            13bytes will expand the message size by 0.4% -->
-            <contentCompressionThreshold>1000</contentCompressionThreshold>
-
-        </contentHandling>
-
-        <inboundEvents>
-            <!--Number of parallel writers used to write content to message store. Increasing this
-            value will speed-up the message receiving mechanism. But the load on the data store will
-            increase.-->
-            <parallelMessageWriters>1</parallelMessageWriters>
-
-            <!--Size of the Disruptor ring buffer for inbound event handling. For publishing at
-            higher rates increasing the buffer size may give some advantage on keeping messages in
-            memory and write.
-
-            NOTE: Buffer size should be a value of power of two -->
-            <bufferSize>65536</bufferSize>
-
-            <!--Maximum batch size of the batch write operation for inbound messages. MB internals
-            use Disruptor to batch events. Hence this batch size is set to avoid database requests
-            with high load (with big batch sizes) to write messages. This need to be configured in
-            high throughput messaging scenarios to regulate the hit on database from MB -->
-            <messageWriterBatchSize>70</messageWriterBatchSize>
-
-            <!--Timeout for waiting for a queue purge event to end to get the purged count. Doesn't
-            affect actual purging. If purge takes time, increasing the value will improve the
-            possibility of retrieving the correct purged count. Having a lower value doesn't stop
-            purge event. Getting the purged count is affected by this -->
-            <purgedCountTimeout>180</purgedCountTimeout>
-
-            <!--Number of parallel writers used to write content to message store for transaction
-            based publishing. Increasing this value will speedup commit duration for a transaction.
-            But the load on the data store will increase.-->
-            <transactionMessageWriters>1</transactionMessageWriters>
-        </inboundEvents>
-
-        <!--Message expiration can be set for each messages which are published to Wso2 MB.
-         After the expiration time, the messages will not be delivered to the consumers. Eventually
-         they got deleted inside the MB.-->
-        <messageExpiration>
-            <!-- When messages delivered, in the delivery path messages were checked whether they are
-            already expired. If expired at that time add that message to a queue for a future batch
-            delete. This interval decides on the time gap between the batch deletes. Time interval
-            specified in seconds.-->
-            <preDeliveryExpiryDeletionInterval>10</preDeliveryExpiryDeletionInterval>
-
-            <!-- Periodically check the database for new expired messages which were not assigned to
-             any slot delivery worker so far and delete them. This interval decides on the time gap between
-             the periodic message deletion. Time interval specified in seconds.-->
-            <periodicMessageDeletionInterval>900</periodicMessageDeletionInterval>
-
-            <!-- When checking the database for expired messages, the messages which were handled by the slot
-            delivery worker should no be touched since that mess up the slot delivery worker functionality.
-            Those messages anyways get caught at the message delivery path. So there is a need to have a safe
-            buffer of slots which can be allocated to a slot delivery worker in the near future. The specified
-            number of slots from the last assigned should not be touched by the periodic deletion task.-->
-            <safetySlotCount>3</safetySlotCount>
-        </messageExpiration>
-
-    </performanceTuning>
-
-    <!-- This section is about how you want to view messaging statistics from the admin console and
-    how you plan to interact with it. -->
-    <managementConsole>
-        <!--Maximum number of messages to be fetched per page using Andes message browser when browsing
-        queues/dlc -->
-        <messageBrowsePageSize>100</messageBrowsePageSize>
-
-        <!-- This property defines the maximum message content length that can be displayed at the
-        management console when browsing queues. If the message length exceeds the value, a
-        truncated content will be displayed with a statement "message content too large to display."
-        at the end. default value is 100000 (can roughly display a 100KB message.)
-        * NOTE : Increasing this value could cause delays when loading the message content page.-->
-        <maximumMessageDisplayLength>100000</maximumMessageDisplayLength>
-
-        <!--Enable users to reroute all messages from a specific destination(queue or durable topic) to a specific
-        queue.-->
-        <allowReRouteAllInDLC>false</allowReRouteAllInDLC>
-    </managementConsole>
-
-    <!-- Memory and resource exhaustion is something we should prevent and recover from.
-    This section allows you to specify the threshold at which to reduce/stop frequently intensive
-    operations within MB temporarily. -->
+
+	1. For message persistence ("messageStore")
+	2. To persist and access other information relevant to messaging protocols.("contextStore").-->
+
+	<!-- By default WSO2 MB runs with H2 persistent store. If you plan to use a different
+	store, point to the relevant dataSource or uncomment the database appropriately.
+
+	RDBMS
+	=====
+	If you are running an RDBMS you can use the existing RDBMS implementation of stores
+	by pointing to the correct data source by updating the property "dataSource".
+
+	Data source entry should be present in
+	<MB_HOME>/repository/conf/datasources/master-datasources.xml.
+
+	-->
+	<persistence>
+
+		<!-- RDBMS MB Store Configuration -->
+
+		<messageStore class="org.wso2.andes.store.rdbms.RDBMSMessageStoreImpl">
+			<property name="dataSource">WSO2MBStoreDB</property>
+			<property name="storeUnavailableSQLStateClasses">08</property>
+			<property name="integrityViolationSQLStateClasses">23,27,44</property>
+			<property name="dataErrorSQLStateClasses">21,22</property>
+			<property name="transactionRollbackSQLStateClasses">40</property>
+		</messageStore>
+
+		<contextStore class="org.wso2.andes.store.rdbms.RDBMSAndesContextStoreImpl">
+			<property name="dataSource">WSO2MBStoreDB</property>
+			<property name="storeUnavailableSQLStateClasses">08</property>
+			<property name="integrityViolationSQLStateClasses">23,27,44</property>
+			<property name="dataErrorSQLStateClasses">21,22</property>
+			<property name="transactionRollbackSQLStateClasses">40</property>
+		</contextStore>
+
+		<cache>
+			<!-- Size of the messages cache in MBs. Setting '0' will disable the cache. -->
+			<size>256</size>
+			<!-- Expected concurrency for the cache (4 is guava default) -->
+			<concurrencyLevel>4</concurrencyLevel>
+			<!--Number of seconds cache will keep messages after they are
+							  added (unless they are consumed and deleted).-->
+			<expirySeconds>2</expirySeconds>
+
+			<!--Reference type used to hold messages in memory.
+					weak   - Using java weak references ( - results higher cache misses)
+					strong - ordinary references ( - higher cache hits, but not good if server
+							 is going to run with limited heap size + under severe load).
+			-->
+			<valueReferenceType>strong</valueReferenceType>
+
+			<!--Prints cache statistics in 2 minute intervals
+												   in carbon log ( and console)-->
+			<printStats>false</printStats>
+		</cache>
+
+		<!-- This class decides how unique IDs are generated for the MB node. This id generator is
+		expected to be thread safe and a implementation of interface
+		org.wso2.andes.server.cluster.coordination.MessageIdGenerator
+
+		NOTE: This is NOT used in MB to generate message IDs. -->
+		<idGenerator>org.wso2.andes.server.cluster.coordination.TimeStampBasedMessageIdGenerator</idGenerator>
+
+		<!-- This is the Task interval (in SECONDS) to check whether communication
+		is healthy between message store (/Database) and this server instance. -->
+		<storeHealthCheckInterval>10</storeHealthCheckInterval>
+	</persistence>
+
+	<!--Publisher transaction related configurations.-->
+	<transaction>
+
+		<!--Maximum batch size (Messages) in kilobytes for a transaction. Exceeding this limit will
+		 result in a failure in the subsequent commit (or prepare) request. Default is set to 1MB.
+		 Limit is calculated considering the payload of messages.-->
+		<maxBatchSizeInKB>10240</maxBatchSizeInKB>
+
+		<!-- Maximum number of parallel dtx enabled channel count. Distributed transaction
+		 requests exceeding this limit will fail. -->
+		<maxParallelDtxChannels>20</maxParallelDtxChannels>
+	</transaction>
+
+	<!-- This section allows you to tweak memory and processor allocations used by WSO2 MB.
+	Broken down by critical processes so you have a clear view of which parameters to change in
+	different scenarios.  -->
+	<performanceTuning>
+
+		<slots>
+
+			<!--Rough estimate for size of a slot. What is meant by size is the number of messages
+			contained within bounties of a slot. -->
+			<windowSize>1000</windowSize>
+
+			<!--
+			If message publishers are slow, time taken to fill the slot (up to <windowSize>) will be longer.
+			This will add an latency to messages. Therefore broker will mark the slot as
+			ready to deliver before even the slot is entirely filled after specified time.
+			NOTE: specified in milliseconds.
+			-->
+			<messageAccumulationTimeout>2000</messageAccumulationTimeout>
+
+			<!-- Time interval which broker check for slots that can be marked as 'ready to deliver'
+				 (- slots which have a aged more than 'messageAccumulationTimeout')
+				 NOTE: specified in milliseconds.
+			-->
+			<maxSubmitDelay>1000</maxSubmitDelay>
+
+			<!--Number of MessageDeliveryWorker threads that should be started-->
+			<deliveryThreadCount>5</deliveryThreadCount>
+
+			<!-- Number of parallel threads to execute slot deletion task. Increasing this value will remove slots
+				 whose messages are read/delivered to consumers/acknowledged faster reducing heap memory used by
+				 server.-->
+			<deleteThreadCount>5</deleteThreadCount>
+
+			<!-- Max number of pending message count to delete per Slot Deleting Task. This config is used to raise
+			 a WARN when pending scheduled number of slots exceeds this limit (indicate of an  issue that can lead to
+			 message accumulation on server.-->
+			<SlotDeleteQueueDepthWarningThreshold>1000</SlotDeleteQueueDepthWarningThreshold>
+
+			<!-- Maximum number of thrift client connections that should be created in the thrift connection pool -->
+			<thriftClientPoolSize>10</thriftClientPoolSize>
+
+		</slots>
+
+		<delivery>
+			<!-- Maximum number of undelivered messages that can have in memory. Increasing this
+			value increase the possibility of out of memory scenario but performance will be
+			improved -->
+			<maxNumberOfReadButUndeliveredMessages>1000</maxNumberOfReadButUndeliveredMessages>
+
+			<!-- This is the ring buffer size of the delivery disruptor. This value should be a
+			power of 2 (E.g. 1024, 2048, 4096). Use a small ring size if you want to reduce the
+			memory usage. -->
+			<ringBufferSize>4096</ringBufferSize>
+
+			<!--Number of parallel readers used to used to read content from message store.
+			Increasing this value will speed-up the message sending mechanism. But the load
+			on the data store will increase. -->
+			<parallelContentReaders>5</parallelContentReaders>
+
+			<!-- Number of parallel decompression handlers used to decompress messages before send to subscribers.
+			Increasing this value will speed-up the message decompressing mechanism. But the system load
+			will increase. -->
+			<parallelDecompressionHandlers>5</parallelDecompressionHandlers>
+
+			<!-- Number of parallel delivery handlers used to send messages to subscribers.
+			Increasing this value will speed-up the message sending mechanism. But the system load
+			will increase. -->
+			<parallelDeliveryHandlers>5</parallelDeliveryHandlers>
+
+			<!-- The size of the batch represents, at a given time the number of messages that could
+			be retrieved from the database. -->
+			<contentReadBatchSize>65000</contentReadBatchSize>
+
+			<contentCache>
+				<!-- Specify the maximum number of entries the cache may contain. -->
+				<maximumSize>100</maximumSize>
+				<!-- Specify the time in seconds that each entry should be
+					 automatically removed from the cache after the entry's creation. -->
+				<expiryTime>120</expiryTime>
+			</contentCache>
+
+			<!--When delivering topic messages to multiple topic
+				subscribers one of following stratigies can be choosen.
+
+			   1. DISCARD_NONE     - Broker do not loose any message to any subscriber.
+									 When there are slow subscribers this can cause broker
+									 go Out of Memory.
+
+			   2. SLOWEST_SUB_RATE - Broker deliver to the speed of the slowest
+									 topic subscriber. This can cause fast subscribers
+									 to starve. But eliminate Out of Memory issue.
+
+			   3. DISCARD_ALLOWED  - Broker will try best to deliver. To eliminate Out
+									 of Memory threat broker limits sent but not acked message
+									 count to <maxUnackedMessages>.
+									 If it is breached, and <deliveryTimeout> is also
+									 breached message can either be lost or actually
+									 sent but ack is not honoured.
+			-->
+			<topicMessageDeliveryStrategy>
+				<strategyName>DISCARD_NONE</strategyName>
+				<!-- If you choose DISCARD_ALLOWED topic message delivery strategy,
+					 broker keep messages in memory until ack is done until this timeout.
+					 If an ack is not received under this timeout, ack will be simulated
+					 internally and real acknowledgement is discarded.
+					 deliveryTimeout is in seconds -->
+				<deliveryTimeout>60</deliveryTimeout>
+			</topicMessageDeliveryStrategy>
+		</delivery>
+
+		<ackHandling>
+			<!--Number of message acknowledgement handlers to process acknowledgements concurrently.
+			These acknowledgement handlers will batch and process acknowledgements.  -->
+			<ackHandlerCount>1</ackHandlerCount>
+
+			<!--Maximum batch size of the acknowledgement handler. Andes process acknowledgements in
+			batches using Disruptor Increasing the batch size reduces the number of calls made to
+			database by MB. Depending on the database optimal batch size this value should be set.
+			Batches will be of the maximum batch size mostly in high throughput scenarios.
+			Underlying implementation use Disruptor for batching hence will batch message at a
+			lesser value than this in low throughput scenarios -->
+			<ackHandlerBatchSize>100</ackHandlerBatchSize>
+
+			<!-- Message delivery from server to the client will be paused temporarily if number of
+			delivered but unacknowledged message count reaches this size. Should be set considering
+			message consume rate. This is to avoid overwhelming slow subscribers. -->
+			<maxUnackedMessages>1000</maxUnackedMessages>
+		</ackHandling>
+
+		<contentHandling>
+
+			<!-- Within Andes there are content chunk handlers which convert incoming large content
+			chunks into max content chunk size allowed by Andes core. These handlers run in parallel
+			converting large content chunks to smaller chunks.
+
+			If the protocol specific content chunk size is different from the max chunk size allowed
+			by Andes core and there are significant number of large messages published, then having
+			multiple handlers will increase performance. -->
+			<contentChunkHandlerCount>3</contentChunkHandlerCount>
+
+			<!-- Andes core will store message content chunks according to this chunk size. Different
+			database will have limits and performance gains by tuning this parameter.
+
+			For instance in MySQL the maximum table column size for content is less than 65534, which
+			is the default chunk size of AMQP. By changing this parameter to a lesser value we can
+			store large content chunks converted to smaller content chunks within the DB with this
+			parameter. -->
+			<maxContentChunkSize>65500</maxContentChunkSize>
+
+			<!-- This is the configuration to allow compression of message contents, before store messages
+			into the database.-->
+			<allowCompression>false</allowCompression>
+
+			<!-- This is the configuration to change the value of the content compression threshold (in bytes).
+			Message contents less than this value will not compress, even compression is enabled. The recommended
+			message size of the smallest message before compression is 13bytes. Compress messages smaller than
+			13bytes will expand the message size by 0.4% -->
+			<contentCompressionThreshold>1000</contentCompressionThreshold>
+
+		</contentHandling>
+
+		<inboundEvents>
+			<!--Number of parallel writers used to write content to message store. Increasing this
+			value will speed-up the message receiving mechanism. But the load on the data store will
+			increase.-->
+			<parallelMessageWriters>1</parallelMessageWriters>
+
+			<!--Size of the Disruptor ring buffer for inbound event handling. For publishing at
+			higher rates increasing the buffer size may give some advantage on keeping messages in
+			memory and write.
+
+			NOTE: Buffer size should be a value of power of two -->
+			<bufferSize>65536</bufferSize>
+
+			<!--Maximum batch size of the batch write operation for inbound messages. MB internals
+			use Disruptor to batch events. Hence this batch size is set to avoid database requests
+			with high load (with big batch sizes) to write messages. This need to be configured in
+			high throughput messaging scenarios to regulate the hit on database from MB -->
+			<messageWriterBatchSize>70</messageWriterBatchSize>
+
+			<!--Timeout for waiting for a queue purge event to end to get the purged count. Doesn't
+			affect actual purging. If purge takes time, increasing the value will improve the
+			possibility of retrieving the correct purged count. Having a lower value doesn't stop
+			purge event. Getting the purged count is affected by this -->
+			<purgedCountTimeout>180</purgedCountTimeout>
+
+			<!--Number of parallel writers used to write content to message store for transaction
+			based publishing. Increasing this value will speedup commit duration for a transaction.
+			But the load on the data store will increase.-->
+			<transactionMessageWriters>1</transactionMessageWriters>
+		</inboundEvents>
+
+		<!--Message expiration can be set for each messages which are published to Wso2 MB.
+		 After the expiration time, the messages will not be delivered to the consumers. Eventually
+		 they got deleted inside the MB.-->
+		<messageExpiration>
+			<!-- When messages delivered, in the delivery path messages were checked whether they are
+			already expired. If expired at that time add that message to a queue for a future batch
+			delete. This interval decides on the time gap between the batch deletes. Time interval
+			specified in seconds.-->
+			<preDeliveryExpiryDeletionInterval>10</preDeliveryExpiryDeletionInterval>
+
+			<!-- Periodically check the database for new expired messages which were not assigned to
+			 any slot delivery worker so far and delete them. This interval decides on the time gap between
+			 the periodic message deletion. Time interval specified in seconds.-->
+			<periodicMessageDeletionInterval>900</periodicMessageDeletionInterval>
+
+			<!-- When checking the database for expired messages, the messages which were handled by the slot
+			delivery worker should no be touched since that mess up the slot delivery worker functionality.
+			Those messages anyways get caught at the message delivery path. So there is a need to have a safe
+			buffer of slots which can be allocated to a slot delivery worker in the near future. The specified
+			number of slots from the last assigned should not be touched by the periodic deletion task.-->
+			<safetySlotCount>3</safetySlotCount>
+		</messageExpiration>
+
+	</performanceTuning>
+
+	<!-- This section is about how you want to view messaging statistics from the admin console and
+	how you plan to interact with it. -->
+	<managementConsole>
+		<!--Maximum number of messages to be fetched per page using Andes message browser when browsing
+		queues/dlc -->
+		<messageBrowsePageSize>100</messageBrowsePageSize>
+
+		<!-- This property defines the maximum message content length that can be displayed at the
+		management console when browsing queues. If the message length exceeds the value, a
+		truncated content will be displayed with a statement "message content too large to display."
+		at the end. default value is 100000 (can roughly display a 100KB message.)
+		* NOTE : Increasing this value could cause delays when loading the message content page.-->
+		<maximumMessageDisplayLength>100000</maximumMessageDisplayLength>
+
+		<!--Enable users to reroute all messages from a specific destination(queue or durable topic) to a specific
+		queue.-->
+		<allowReRouteAllInDLC>false</allowReRouteAllInDLC>
+	</managementConsole>
+
+	<!-- Memory and resource exhaustion is something we should prevent and recover from.
+	This section allows you to specify the threshold at which to reduce/stop frequently intensive
+	operations within MB temporarily. -->
 	<!--
 	highLimit - flow control is enabled when message chunk pending to be handled by inbound 
 	 disruptor reaches above this limit
     lowLimit - flow control is disabled (if enabled) when message chunk pending to be handled
 	 by inbound disruptor reaches below this limit	
-	-->	
-    <flowControl>
-        <!-- This is the global buffer limits which enable/disable the flow control globally -->
-        <global>
-            <lowLimit>800</lowLimit>
-            <highLimit>8000</highLimit>
-        </global>
-
-        <!-- This is the channel specific buffer limits which enable/disable the flow control locally.
+	-->
+	<flowControl>
+		<!-- This is the global buffer limits which enable/disable the flow control globally -->
+		<global>
+			<lowLimit>800</lowLimit>
+			<highLimit>8000</highLimit>
+		</global>
+
+		<!-- This is the channel specific buffer limits which enable/disable the flow control locally.
 		-->
-        <bufferBased>
-            <lowLimit>100</lowLimit>
-            <highLimit>1000</highLimit>
-        </bufferBased>
-    </flowControl>
-
-    <slotManagement>
-        <!--Set slot storage mode (RDBMS/HazelCast)-->
-        <storage>RDBMS</storage>
-    </slotManagement>
-	
-    <!--
-    Message broker keeps track of all messages it has received as groups. These groups are termed
-    'Slots' (To know more information about Slots and message broker install please refer to online wiki).
-    Size of a slot is loosely determined by the configuration <windowSize> (and the number of
-    parallel publishers for specific topic/queue). Message broker cluster (or in single node) keeps
-    track of slots which constitutes for a large part of operating state before the cluster went down.
+		<bufferBased>
+			<lowLimit>100</lowLimit>
+			<highLimit>1000</highLimit>
+		</bufferBased>
+	</flowControl>
+
+	<!--
+	Message broker keeps track of all messages it has received as groups. These groups are termed
+	'Slots' (To know more information about Slots and message broker install please refer to online wiki).
+	Size of a slot is loosely determined by the configuration <windowSize> (and the number of
+	parallel publishers for specific topic/queue). Message broker cluster (or in single node) keeps
+	track of slots which constitutes for a large part of operating state before the cluster went down.
 	When first message broker node of the cluster starts up, it will read the database to recreate
-    the internal state to previous state. 
-    -->
-    <recovery>
-        <!--
-        There could be multiple storage queues worked before entire cluster (or single node) went down.
-        We need to recover all remaining messages of each storage queue when first node startup and we can
-        read remaining message concurrently of each storage queue. Default value to set here to 5. You can
-        increase this value based on number of storage queues exist. Please use optimal value based on
-        number of storage queues to speed up warm startup.
-        -->
-        <concurrentStorageQueueReads>5</concurrentStorageQueueReads>
-
-        <!-- Virtual host sync interval seconds in for the Virtual host syncing Task which will
-            sync the Virtual host details across the cluster -->
-        <vHostSyncTaskInterval>900</vHostSyncTaskInterval>
-        
-        <!--
-         Enables network partition detection ( and surrounding functionality, such
-         as disconnecting subscriptions, enabling error based flow control if the
-         minimal node count becomes less than configured value.
-        -->
-        <networkPartitionsDetection enabled = "false">
-              
-               <!--
-                The minimum node count the cluster should maintain for this node to
-                operate. if cluster size becomes less that configured value
-                This node will not accept any incoming traffic ( and disconnect
-                subscriptions) etc.
-               -->
-              <minimumClusterSize>1</minimumClusterSize>
-        </networkPartitionsDetection>
-
-    </recovery>
-
-    <!--
-        Specifies the deployment mode for the broker node (and cluster). Possible values {default, standalone}.
-
-        default - Broker node will decide to run HA (master/slave) or fully distributed mode. Decision is taken based
-                  on the node has a clustering mechanism enabled or not. If the node is not configured to join a cluster
-                  it will run in HA mode (refer to axis2.xml for more information). If the node can join a cluster it
-                  will start in fully clustered mode.
-
-        standalone - This is the simplest mode a broker can be started. Node will assume datastore is not shared with
-                     another node. Therefore it will not try to coordinate with other nodes (possibly non-existent) to
-                     provide HA or clustering.
-    -->
-    <deployment>
-        <mode>default</mode>
-    </deployment>
+	the internal state to previous state.
+	-->
+	<recovery>
+		<!--
+		There could be multiple storage queues worked before entire cluster (or single node) went down.
+		We need to recover all remaining messages of each storage queue when first node startup and we can
+		read remaining message concurrently of each storage queue. Default value to set here to 5. You can
+		increase this value based on number of storage queues exist. Please use optimal value based on
+		number of storage queues to speed up warm startup.
+		-->
+		<concurrentStorageQueueReads>5</concurrentStorageQueueReads>
+
+		<!-- Virtual host sync interval seconds in for the Virtual host syncing Task which will
+			sync the Virtual host details across the cluster -->
+		<vHostSyncTaskInterval>900</vHostSyncTaskInterval>
+
+		<!--
+		 Enables network partition detection ( and surrounding functionality, such
+		 as disconnecting subscriptions, enabling error based flow control if the
+		 minimal node count becomes less than configured value.
+		-->
+		<networkPartitionsDetection enabled = "false">
+
+			<!--
+				The minimum node count the cluster should maintain for this node to
+				operate. if cluster size becomes less that configured value
+				This node will not accept any incoming traffic ( and disconnect
+				subscriptions) etc.
+			   -->
+			<minimumClusterSize>1</minimumClusterSize>
+		</networkPartitionsDetection>
+
+	</recovery>
+
+	<!--
+		Specifies the deployment mode for the broker node (and cluster). Possible values {default, standalone}.
+
+		default - Broker node will decide to run HA (master/slave) or fully distributed mode. Decision is taken based
+				  on the node has a clustering mechanism enabled or not. If the node is not configured to join a cluster
+				  it will run in HA mode (refer to axis2.xml for more information). If the node can join a cluster it
+				  will start in fully clustered mode.
+
+		standalone - This is the simplest mode a broker can be started. Node will assume datastore is not shared with
+					 another node. Therefore it will not try to coordinate with other nodes (possibly non-existent) to
+					 provide HA or clustering.
+	-->
+	<deployment>
+		<mode>default</mode>
+	</deployment>
 
 </broker>
diff --git a/modules/distribution/src/broker/conf/log4j.properties b/modules/distribution/src/broker/conf/log4j.properties
index f078312c..2b24d892 100644
--- a/modules/distribution/src/broker/conf/log4j.properties
+++ b/modules/distribution/src/broker/conf/log4j.properties
@@ -144,6 +144,9 @@ log4j.appender.CARBON_MEMORY.layout.TenantPattern=%U%@%D [%T] [%S]
 log4j.appender.CARBON_MEMORY.columnList=%T,%S,%A,%d,%c,%p,%m,%H,%I,%Stacktrace
 log4j.appender.CARBON_MEMORY.threshold=DEBUG
 
+# uncomment the following logs to see http calls headers and messages
+#log4j.logger.feign=DEBUG
+
 # CARBON_LOGFILE is set to be a DailyRollingFileAppender using a PatternLayout.
 log4j.appender.CARBON_LOGFILE=org.apache.log4j.DailyRollingFileAppender
 # Log file will be overridden by the configuration setting in the DB
diff --git a/modules/distribution/src/core/conf/identity/identity-providers/iot_default.xml b/modules/distribution/src/core/conf/identity/identity-providers/iot_default.xml
index 9ef53ce1..3fb420bd 100644
--- a/modules/distribution/src/core/conf/identity/identity-providers/iot_default.xml
+++ b/modules/distribution/src/core/conf/identity/identity-providers/iot_default.xml
@@ -36,9 +36,7 @@
 	</ProvisioningConnectorConfigs>
 	<!--<DefaultProvisioningConnectorConfig></DefaultProvisioningConnectorConfig>-->
 	<ClaimConfig></ClaimConfig>
-	<Certificate>
-MIICNTCCAZ6gAwIBAgIES343gjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJVUzELMAkGA1UECAwCQ0ExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxDTALBgNVBAoMBFdTTzIxEjAQBgNVBAMMCWxvY2FsaG9zdDAeFw0xMDAyMTkwNzAyMjZaFw0zNTAyMTMwNzAyMjZaMFUxCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzENMAsGA1UECgwEV1NPMjESMBAGA1UEAwwJbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCUp/oV1vWc8/TkQSiAvTousMzOM4asB2iltr2QKozni5aVFu818MpOLZIr8LMnTzWllJvvaA5RAAdpbECb+48FjbBe0hseUdN5HpwvnH/DW8ZccGvk53I6Orq7hLCv1ZHtuOCokghz/ATrhyPq+QktMfXnRS4HrKGJTzxaCcU7OQIDAQABoxIwEDAOBgNVHQ8BAf8EBAMCBPAwDQYJKoZIhvcNAQEFBQADgYEAW5wPR7cr1LAdq+IrR44iQlRG5ITCZXY9hI0PygLP2rHANh+PYfTmxbuOnykNGyhM6FjFLbW2uZHQTY1jMrPprjOrmyK5sjJRO4d1DeGHT/YnIjs9JogRKv4XHECwLtIVdAbIdWHEtVZJyMSktcyysFcvuhPQK8Qc/E/Wq8uHSCo=
-	</Certificate>
+	<Certificate>MIIDSTCCAjGgAwIBAgIERUubMzANBgkqhkiG9w0BAQsFADBVMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxDTALBgNVBAoTBFdTTzIxEjAQBgNVBAMTCWxvY2FsaG9zdDAeFw0xNzAzMjEwOTEzMDdaFw0xNzA2MTkwOTEzMDdaMFUxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzENMAsGA1UEChMEV1NPMjESMBAGA1UEAxMJbG9jYWxob3N0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu8lfLCQV2hbiz8OGA8baKI1E1cgE/QLKefa4Od2G2KextaAwSESr5ICakVX8w6tU5+IhKYQQKt9U3/U0ae9tXf04g6iWh0dRllsr9mOgjSZxQK09/ygUsFH8syL5aD3heRUYzJWZ/KOsd57BXuI2QZnuEjN0g0+5jNvnswfwD/tM01totaJpI3xN+2JZsaBRCc0G5yA/pdW83Aa4IE30EL57wkK7u8YDl3UTcmi+HO74XQmK1VEqSnA+/mFo3M16cRlm2PTZ2Z1E5gd4j+5sV1P5v63uqyFniEU0zPXforBb06pgSBoIRQBintSSDyEmyuVzW0pc2eYC5Dhfgk337QIDAQABoyEwHzAdBgNVHQ4EFgQU4lneZCvKn04NH5DtJItdRXdXankwDQYJKoZIhvcNAQELBQADggEBAEnCNr0JEcAxtF/ypwGgFu1rYOv3i02PB4jDWbFj8s58l1zF1tMr480khVX4d3AmLjsUpvV+Jg83JFIk1rJFLEb48EFv0nJ/G7pTQrCypNKozyuyLzx5UvKNFBMmnGvkHVqt6j4MSiOjnRdlo7ofDluA/umSkSf/VmsOIZ+5610pCJpahnPUkb8GYK0HcwNV2NLU/0X4nSjKjGwWYv0tX8XW8RwJKb/r0GDehA8PESi76XOVrpXSjP9WPK8XaK//8B0SH3hm0xpzmSQYgtkNQwP2MqBe/ZEUuKxrn3pP6oxo9RxeSIQ8dTLiBA/mcsBmAlpQPPi0LqqDKpkyHt8Ar2w=</Certificate>
 	<PermissionAndRoleConfig></PermissionAndRoleConfig>
 	<JustInTimeProvisioningConfig></JustInTimeProvisioningConfig>
 </IdentityProvider>
\ No newline at end of file
diff --git a/modules/integration/tests-integration/src/test/resources/keystores/products/client-truststore.jks b/modules/integration/tests-integration/src/test/resources/keystores/products/client-truststore.jks
index ab222fdd..c477431c 100644
Binary files a/modules/integration/tests-integration/src/test/resources/keystores/products/client-truststore.jks and b/modules/integration/tests-integration/src/test/resources/keystores/products/client-truststore.jks differ
diff --git a/modules/integration/tests-integration/src/test/resources/keystores/products/wso2carbon.jks b/modules/integration/tests-integration/src/test/resources/keystores/products/wso2carbon.jks
index 79784a5e..11686670 100644
Binary files a/modules/integration/tests-integration/src/test/resources/keystores/products/wso2carbon.jks and b/modules/integration/tests-integration/src/test/resources/keystores/products/wso2carbon.jks differ
diff --git a/modules/integration/tests-integration/src/test/resources/keystores/stratos/client-truststore.jks b/modules/integration/tests-integration/src/test/resources/keystores/stratos/client-truststore.jks
index ab222fdd..c477431c 100644
Binary files a/modules/integration/tests-integration/src/test/resources/keystores/stratos/client-truststore.jks and b/modules/integration/tests-integration/src/test/resources/keystores/stratos/client-truststore.jks differ
diff --git a/modules/integration/tests-integration/src/test/resources/keystores/stratos/wso2carbon.jks b/modules/integration/tests-integration/src/test/resources/keystores/stratos/wso2carbon.jks
index 79784a5e..11686670 100644
Binary files a/modules/integration/tests-integration/src/test/resources/keystores/stratos/wso2carbon.jks and b/modules/integration/tests-integration/src/test/resources/keystores/stratos/wso2carbon.jks differ
diff --git a/modules/p2-profile/analytics-profile/carbon.product b/modules/p2-profile/analytics-profile/carbon.product
index 896c2c70..a2006154 100644
--- a/modules/p2-profile/analytics-profile/carbon.product
+++ b/modules/p2-profile/analytics-profile/carbon.product
@@ -13,7 +13,7 @@
    </plugins>
 
    <features>
-      <feature id="org.wso2.carbon.core.runtime" version="4.4.14"/>
+      <feature id="org.wso2.carbon.core.runtime" version="4.4.16"/>
    </features>
 
   <configurations>
diff --git a/modules/p2-profile/broker-profile/carbon.product b/modules/p2-profile/broker-profile/carbon.product
index 896c2c70..a2006154 100644
--- a/modules/p2-profile/broker-profile/carbon.product
+++ b/modules/p2-profile/broker-profile/carbon.product
@@ -13,7 +13,7 @@
    </plugins>
 
    <features>
-      <feature id="org.wso2.carbon.core.runtime" version="4.4.14"/>
+      <feature id="org.wso2.carbon.core.runtime" version="4.4.16"/>
    </features>
 
   <configurations>
diff --git a/modules/p2-profile/iot-core-profile/carbon.product b/modules/p2-profile/iot-core-profile/carbon.product
index c3ac5fa7..8420ed11 100644
--- a/modules/p2-profile/iot-core-profile/carbon.product
+++ b/modules/p2-profile/iot-core-profile/carbon.product
@@ -14,7 +14,7 @@ version="4.4.14" useFeatures="true" includeLaunchers="true">
    </plugins>
 
    <features>
-      <feature id="org.wso2.carbon.core.runtime" version="4.4.14"/>
+      <feature id="org.wso2.carbon.core.runtime" version="4.4.16"/>
    </features>
 
   <configurations>
diff --git a/modules/p2-profile/iot-core-profile/pom.xml b/modules/p2-profile/iot-core-profile/pom.xml
index c46b7ffb..177a7501 100644
--- a/modules/p2-profile/iot-core-profile/pom.xml
+++ b/modules/p2-profile/iot-core-profile/pom.xml
@@ -182,6 +182,9 @@
                                 <featureArtifactDef>
                                     org.wso2.carbon.devicemgt-plugins:org.wso2.carbon.device.mgt.iot.androidsense.backend.feature:${carbon.device.mgt.plugin.version}
                                 </featureArtifactDef>
+								<featureArtifactDef>
+									org.wso2.carbon.devicemgt-plugins:org.wso2.carbon.device.mgt.notification.listener.feature:${carbon.device.mgt.plugin.version}
+								</featureArtifactDef>
                                 <!-- End of Device Management Plugin Features -->
 
                                 <!-- IoT Device Management Features -->
@@ -1016,6 +1019,10 @@
                                     <id>org.wso2.carbon.device.mgt.iot.androidsense.backend.feature.group</id>
                                     <version>${carbon.device.mgt.plugin.version}</version>
                                 </feature>
+								<feature>
+									<id>org.wso2.carbon.device.mgt.notification.listener.feature.group</id>
+									<version>${carbon.device.mgt.plugin.version}</version>
+								</feature>
                                 <!-- End of Device Management Features -->
                                 <feature>
                                     <id>org.wso2.carbon.device.mgt.adapter.feature.group</id>
@@ -1136,6 +1143,10 @@
                                     <id>org.wso2.carbon.databridge.datapublisher.feature.group</id>
                                     <version>${carbon.analytics.common.version}</version>
                                 </feature>
+								<feature>
+									<id>org.wso2.carbon.event.input.adapter.server.feature.group</id>
+									<version>${carbon.analytics.common.version}</version>
+								</feature>
                                 <!-- End of Carbon Analytics Common Features -->
 
                                 <feature>
@@ -2015,6 +2026,10 @@
                                     <id>org.wso2.carbon.device.mgt.mobile.windows.feature.group</id>
                                     <version>${carbon.device.mgt.plugin.version}</version>
                                 </feature>
+								<feature>
+									<id>org.wso2.carbon.device.mgt.notification.listener.feature.group</id>
+									<version>${carbon.device.mgt.plugin.version}</version>
+								</feature>
                                 <feature>
                                     <id>org.wso2.carbon.device.mgt.analytics.dashboard.feature.group</id>
                                     <version>${carbon.device.mgt.version}</version>
@@ -2647,6 +2662,10 @@
                                     <id>org.wso2.carbon.device.mgt.mobile.windows.feature.group</id>
                                     <version>${carbon.device.mgt.plugin.version}</version>
                                 </feature>
+								<feature>
+									<id>org.wso2.carbon.device.mgt.notification.listener.feature.group</id>
+									<version>${carbon.device.mgt.plugin.version}</version>
+								</feature>
                                 <feature>
                                     <id>org.wso2.carbon.device.mgt.analytics.dashboard.feature.group</id>
                                     <version>${carbon.device.mgt.version}</version>
diff --git a/pom.xml b/pom.xml
index 643baf36..b9a4a003 100644
--- a/pom.xml
+++ b/pom.xml
@@ -1440,7 +1440,7 @@
     <properties>
 
         <!--Carbon kernel versions-->
-        <carbon.kernel.version>4.4.14</carbon.kernel.version>
+        <carbon.kernel.version>4.4.16</carbon.kernel.version>
         <carbon.kernel.version.range>[4.4.0, 4.5.0)</carbon.kernel.version.range>
         <carbon.ui.menu.stratos.version>2.2.0</carbon.ui.menu.stratos.version>
 
@@ -1512,7 +1512,7 @@
 
         <!-- Carbon Device Management -->
 
-        <carbon.device.mgt.version>2.0.68</carbon.device.mgt.version>
+        <carbon.device.mgt.version>2.0.69-SNAPSHOT</carbon.device.mgt.version>
         <carbon.device.mgt.version.range>[2.0.0, 3.0.0)</carbon.device.mgt.version.range>
 
         <!-- IOT Device Management -->
@@ -1520,7 +1520,7 @@
 
         <!-- Carbon Device Management Plugins-->
 
-        <carbon.device.mgt.plugin.version>3.0.36</carbon.device.mgt.plugin.version>
+        <carbon.device.mgt.plugin.version>3.0.37-SNAPSHOT</carbon.device.mgt.plugin.version>
 
         <!-- API Management -->
         <carbon.api.mgt.version>6.1.80</carbon.api.mgt.version>
@@ -1551,8 +1551,8 @@
 
         <!-- IoT Broker Dependencies -->
         <product.iot.broker.version>${product.iot.version}</product.iot.broker.version>
-        <andes.version>3.1.15</andes.version>
-        <carbon.messaging.version>3.1.17</carbon.messaging.version>
+        <andes.version>3.2.19</andes.version>
+        <carbon.messaging.version>3.2.15</carbon.messaging.version>
 
         <!-- Third Party Dependencies-->
         <spongycastle.version>1.51.0.0</spongycastle.version>