| Anchor | ||||
|---|---|---|---|---|
|
| Table of Contents | ||||
|---|---|---|---|---|
|
...
| Duplicates Allowed | Consumer applications specify this the acknowledgement mode using the Recommended only for applications that are tolerant to message duplicates. |
| Auto acknowledge | This is the default acknowledgement mode, which is specified using the
If a JMS provider or the message consumer crashes while it is processing a message, the message will either be re-delivered or lost when using the automatic acknowledgement mode. |
| Client acknowledge | Consumer applications specify this acknowledgement mode using the When a consumer uses client acknowledge, it can use the recover method of the session to revert back to its last checkpoint. This causes the session to re-deliver all messages that have not yet been acknowledged by the consumer. If a client crashes and later re-connects to its queue or topic, the session will effectively be recovered and the consumer will receive all unacknowledged messages. |
| Transactional Acknowledge | A transacted session is a related group of consumed and produced messages that are treated as a single work unit. A transaction can either be either committed or rolled back. When the session's commit method is called, the consumed messages are acknowledged, and the associated produced messages are sent. When a session's rollback method is called, the produced messages are destroyed, and the consumed messages are recovered. As soon as either the commit or rollback method is called, the current transaction ends and a new transaction is immediately started. For example, if an application moves messages from one destination to another, it should use a transacted session to ensure that the message is either successfully transferred, or not transferred at all. In this case, the commit method should be called after each message. |
How to archive clustering with JMS?
...
. |
...
How to use JMS transactions?
Refer to section See JMS Transactions.
...
How to respond to the client after sending a SOAP request to
...
a JMS queue?
This can be achieved with the following configuration. Replace Replace the following line according to your end point URI: <address uri=" http://localhost:9000/services/SimpleStockQuoteService "/>.
| Code Block | ||
|---|---|---|
| ||
<definitions xmlns="http://ws.apache.org/ns/synapse">
<registry provider="org.wso2.carbon.mediation.registry.WSO2Registry">
<parameter name="cachableDuration">15000</parameter>
</registry>
<proxy name="StockQuoteProxy"
transports="http"
startOnLoad="true"
trace="disable">
<description/>
<target>
<inSequence>
<property name="OUT_ONLY" value="true"/>
<clone>
<target>
<endpoint>
<address uri="http://localhost:9000/services/SimpleStockQuoteService"/>
</endpoint>
</target>
<target sequence="test"/>
</clone>
</inSequence>
<outSequence>
<send/>
</outSequence>
</target>
</proxy>
<sequence name="test">
<payloadFactory>
<format>
<ns:a xmlns:ns="http://services.samples">
<ns:b>Accepted</ns:b>
</ns:a>
</format>
</payloadFactory>
<property name="HTTP_SC" value="202" scope="axis2"/>
<header name="To" action="remove"/>
<property name="RESPONSE" value="true"/>
<send/>
</sequence>
<sequence name="fault">
<log level="full">
<property name="MESSAGE" value="Executing default 'fault' sequence"/>
<property name="ERROR_CODE" expression="get-property('ERROR_CODE')"/>
<property name="ERROR_MESSAGE" expression="get-property('ERROR_MESSAGE')"/>
</log>
<drop/>
</sequence>
<sequence name="main">
<in>
<log level="full"/>
<filter source="get-property('To')" regex="http://localhost:9000.*">
<send/>
</filter>
</in>
<out>
<send/>
</out>
<description>The main sequence for the message mediation</description>
</sequence>
</definitions> |
...
Does
...
the ESB Profile of WSO2 Enterprise Integrator implement JMS queues with disk persistence?
If the broker supports JMS message persistence, the ESB Profile of WSO2 EI can read/write from a persistence message queue.
...
How does
...
the ESB Profile of WSO2 Enterprise Integrator manage message recalling when the destination queue cannot be reached?
You can define message stores to handle failed messages.
...
If you have sent messages through a JMS endpoint to an unavailable data services server, messages will get queued at the JMS broker. When you start the data services server service soon after, the JMS queue will be consumed by the serverdata service. But, there can be a message loss due to the unavailability of the data source if it is configured as a Carbon Data Source.
...
2. Add the following parameters to the data service. If WSO2 EI's management console UI Management Console of the ESB Profile of WSO2 Enterprise Integrator is used to add themthe parameters, you can first add the name first and then enter the values after saving.
| Code Block | ||
|---|---|---|
| ||
<parameter name="transport.jms.SessionAcknowledgement" locked="false">CLIENT_ACKNOWLEDGE</parameter> <parameter name="transport.jms.CacheLevel" locked="false">none</parameter> |
This will ensure that no messages will be are not lost even if the data source is not available at the initialization. You might notice exceptions in the log but the inserts will be done to the database accordingly.
...