This chapter lists all the functions by category. If you know what you want to do, but do not know which function to use, look it up in this chapter. If you know the name of a function and want a complete description of it, you can find it in the chapter "Function Reference".

Lookup of Administered Objects

FioranoMQ supports lookup of administered objects using the JNDI interface. In case of the CRTL this support has been provided using an InitialContext structure that works mostly on the lines of the InitialContext object of JNDI. Client applications can create an IntialContext and lookup different administered objects from the FioranoMQ server.

Creating InitialContext

The InitialContext is used to search for administered objects from the FioranoMQ server. The lookup operation performed by the InitialContext in the CRTL is similar to how it is done in Java using JNDI (Java Naming and Directory Interface). The only difference is that there is no entity called IntialContextFactory in the CRTL.
CRTL contains several APIs for creating the InitialContext. These can be sub-di-vided into two major categories:

• APIs that have individual parameters as arguments
• APIs that take a Hashtable environment as argument

In this case the different parameters required for creating the InitialContext like username, password, providerURL, and transport protocol are passed as separate arguments to the API. The table below lists these APIs with a brief purpose of each.

APIs that take a Hashtable environment as argument
The InitialContext can be created by passing all required environment parameters and their values in a Hashtable structure.The permissible name and values of some of these parameters can be checked in the chapter on datatypes and constants. For more information on creating and populating the hashtable structure, refer to the UtilityAPIs section of this chapter.

HTTP support using the IntialContext

The HTTP mode allows client applications to connect to the FioranoMQ server run-ning in HTTP mode, both directly and through proxy servers. The only change re-quired in the application for using HTTP is while creating the InitialContext object. The following functions can be used to connect to the server, using the HTTP pro-tocol:
InitialContext newInitialContext_HTTP(mqstring url, mqstring user-name, mqstring passwd);
The above function is provided specifically for using HTTP protocol. However it does not allow you to specify a proxy server.
InitialContext newInitialContext_env(struct _Hashtable* env);
The above function is a more generic function, which accepts various parameters in a hashtable. This function can be used for all the protocols such as TCP, SSL, HTTP, and HTTPS. The following variables can be specified in the hashtable to configure the transport layer for HTTP:

• SECURITY_PRINCIPAL Username, which is used to perform lookup at the FioranoMQ server.
• SECURITY_CREDENTIALS Password for the user.
• PROVIDER_URL URL of the FioranoMQ server to connect to
• TRANSPORT_PROTOCOL Transport protocol to be used (HTTP in this case).
• HTTP_PROXY_URL URL of the proxy server to be used. If not specified, the runtime sends the request directly to the FioranoMQ server.
• HTTP_PROXY_TYPE Type of proxy server.
• PROXY_AUTHENTICATION_REALM Not supported currently.
• PROXY_PRINCIPAL Username to be used for connecting to the proxy server.
• PROXY_CREDENTIALS Password for the proxy user.
• FORCE_HTTP_10 Certain proxy servers do not support HTTP/1.1 persistent connections. For such servers, the flag "FORCE_HTTP_10" has to be set to TRUE.

The following code snippet has been extracted from an application using HTTP protocol.
InitialContext ic = NULL;
Hashtable env = newHashtable ();
HT_Put (env, SECURITY_PRINCIPAL, "anonymous");
HT_Put (env, SECURITY_CREDENTIALS, "anonymous");
HT_Put (env, PROVIDER_URL, "http://localhost:1856/");
HT_Put (env, HTTP_PROXY_URL, "http://localhost:8080");
HT_Put (env, HTTP_PROXY_TYPE, "MS_ISA_PROXY");
HT_Put (env, PROXY_AUTHENTICATION_REALM, "");
HT_Put (env, PROXY_PRINCIPAL, "modena");
HT_Put (env, PROXY_CREDENTIALS, "modena");
HT_Put (env, FORCE_HTTP_10, "TRUE")
ic = newInitialContext_env (env);

HTTPS Support using the InitialContext

The current version of CRTL allows applications to connect to the FioranoMQ server, running in HTTP in the Phaos SSL mode. The following function can be used for configuring InitialContext to use HTTPS protocol.
InitialContext newInitialContext_env(struct _Hashtable* env);
The parameters that can be used for configuring C-runtime in HTTPS mode are as follows:

• SECURITY_PRINCIPAL Username, which is used to perform lookup at the FioranoMQ server.
• SECURITY_CREDENTIALS Password for the user.
• PROVIDER_URL URL of the FioranoMQ server to connect to.
• TRANSPORT_PROTOCOL Transport protocol to be used (HTTPS in this-case).
• HTTP_PROXY_URL URL of the proxy server to be used. If not specified, the runtime sends the request directly to the FioranoMQ server.
• HTTP_PROXY_TYPE Type of proxy server.
• PROXY_AUTHENTICATION_REALM Not supported currently.
• PROXY_PRINCIPAL Username to be used for connecting to the proxy server.
• PROXY_CREDENTIALS Password for the proxy user.
• FORCE_HTTP_10 Certain proxy servers do not support HTTP/1.1 persistent connections. For such servers, the flag "FORCE_HTTP_10" has to be set-TRUE.
• SSL_CERT_FILE Fully qualified path of Certificate file.
• SSL_PRIVATE_KEY_FILE Fully qualified path of the Private key file.
• SSL_PRIVATE_KEY_PASSWORD Password for private key, if it is pass-word-encrypted, else NULL.

The following code snippet has been extracted from an application, which uses HTTPS protocol.
InitialContext ic = NULL; Hashtable env = newHashtable ();HT_Put (env, SECURITY_PRINCIPAL, "anonymous");HT_Put (env, SECURITY_CREDENTIALS, "anonymous");HT_Put (env, PROVIDER_URL, "http://localhost:1856/");HT_Put (env, TRANSPORT_PROTOCOL, HTTPS_PROTOCOL);HT_Put (env, HTTP_PROXY_URL, "http://localhost:8080");HT_Put (env, HTTP_PROXY_TYPE, "MS_ISA_PROXY");HT_Put (env, PROXY_AUTHENTICATION_REALM, "");HT_Put (env, PROXY_PRINCIPAL, "modena");

SSL support using the InitialContext

The only change in the C Client application for communicating with the FioranoMQ server on SSL is the creation of the InitialContext that is used for looking up various administered objects.
For a C client application to connect to the FioranoMQ server running over Phaos SSL, extra environment parameters are required for creating the InitialContext object. These extra parameters are listed below.

• CertFile: This is the digital certificate file. This parameter has to be passed with the fully qualified path name of the file. The certificate file must be in PEM format and must be sorted starting with the certificate to the highest level (root CA).
• PrivateKeyFile: This is the private key file. This parameter has to be passed-with the fully qualified path name of the file. The file must be in the PEM format.
• keyPassword: keyPassword is required if the private key file is encrypted with a password, otherwise a NULL value must be passed.These parameters can be provided to the InitialContext object in one of two possible ways.

These parameters can be added to a Hashtable structure that is provided in the CRTL. For creating a hashtable the fiorano_hashtable.h file needs to be included in the application. The Hashtable can be created using the following API.
Hashtable env = newHashtable ();
The parameters mentioned above can be added to this Hashtable in the following-manner.
HT_Put (env, TRANSPORT_PROTOCOL, SSL_PROTOCOL);
HT_Put (env, SSL_CERT_FILE, "C:
Program Files\\Fiorano\\Fiora-noMQ\\crtl\\bin
dsa-client-cert.der");HT_Put (env, SSL_PRIVATE_KEY_FILE, " C:
Program Files\\Fio-rano\\FioranoMQ\\crtl\\bin
enc-dsa-client-key.pem");HT_PUT(env, SSL_PRIVATE_KEYPASSWORD, "passwd");
Now this Hashtable is used for creating the InitialContext as follows:
InitialContext newInitialContext_env(struct _Hashtable* env);
This InitialContext can now be used to in the same way as it is for Client applications connecting over TCP.
Another way of creating the InitialContext is by using separate APIs for the case of SSL in which the above mentioned parameters are passed as arguments.
InitialContext newInitialContext_SSL(mqstring url, mqstring user-
name, mqstring passwd,mqstring certFile, mqstring privateKeyFile, mqstring keyPass);InitialContext newInitialContext1_SSL(mqstring serverName, mqint port, mqstring username,mqstring passwd, mqstring certFile, mqstring privateKeyFile, mqstring keyPass); h2.Looking up Objects using InitialContext
A single API is provided for looking up any administered object from the FioranoMQ server. The name of the administered object is provided as an argument to the API. The API returns an mqobject that has to be type-casted into the structure of the administered object that is being looked up. The objects that can be looked up using the InitialContext are Topic, TopicConnectionFactory, Queue, and QueueConnectionFactory.

Destroying the InitialContext

The InitialContext created in CRTL should be destroyed before the user program exits to avoid any memory leaks, using the following function.

Following code snippet shows the use of the InitialContext.
InitialContext ic = NULL;
Queue queue = NULL;Topic topic = NULL;ic = newInitialContext("http://mymachine:1856","ayrton", "senna");//...queue = (Queue)IC_lookup(ic, "primaryqueue");topic = (Topic)IC_lookup(ic, "primarytopic");//...IC_free(ic);//...//Free other objects before exit

Point to Point Model

Using a QueueConnectionFactory

The QueueConnectionFactory is a factory object used to create QueueConnections with the FioranoMQ server. A ConnectionFactory object encapsulates a set of connection configuration parameters that has been defined by an administrator.This is an administered object and should be looked up from the FioranoMQ server using the InitialContext (as explained in the section Lookup Administered Objects of this chapter). The user cannot create QueueConnectionFactory object using the CRTL. This can be done using the FioranoMQ AdminTool or by using the admin APIs provided in the default Java RTL.
One of the predefined QueueConnectionFactory objects in the FioranoMQ server is the primaryQCF. This is used in all the examples explained in the document where a QCF is necessary.

Creating a QueueConnection

QueueConnectionFactories are used to create QueueConnections with the FioranoMQ server. The QueueConnection is created with the server running on the ConnectURL specified in the QueueConnectionFactory and if the same is unavailable then the RTL tries to make a connection with a BackupURL, if any.
QueueConnections can be created using default user identity ("anony-mous","anonymous" in case of FioranoMQ) or by specifying a username and password.

Destroying a QueueConnectionFactory

Before quitting, the QueueConnectionFactory object, created in the application, should be destroyed using the following function.

The following code sample looks up a QueueConnectionFactory from the FioranoMQ server and uses it to create a QueueConnection.
QueueConnectionFactory qcf = NULL;
//...qcf = (QueueConnectionFactory)IC_Lookup(ic,"primaryQCF");qc = QCF_createQueueConnection(qcf, "ayrton", "senna");//...QCF_free(qcf);//...//Free other objects before exit. h2.Using a QueueConnection
The QueueConnection is an active connection to the FioranoMQ server. It is used to create one or more queue sessions for producing and consuming messages. It is created using the QueueConnectionFactory. For more information, read the Using a QueueConnectionFactory section of this chapter.

Starting and Stopping a QueueConnection

The delivery of messages on a connection is controlled by the start and stop APIs. Starting a connection starts or resumes the delivery of messages to consumers on that connection. Likewise, stopping the connection temporarily stops the delivery of messages to all consumers on that connection.
The ExceptionListener functionality is enabled only if the connection is started. The following APIs are used to control the start and stop of QueueConnections.

ExceptionListener and ClientID of a QueueConnection

ExceptionListeners are used to check for error conditions on a QueueConnection. Users can set and get ExceptionListeners on a QueueConnection.
The ExceptionListener is not a structure but a callback function in the CRTL that is defined as:
void (*ExceptionListenerPointer)(char *exception, void *pParam);
The client applications have to set the function pointer of the above callback function as the ExceptionListener.When an exception occurs on a connection the same callback function is invoked by the CRTL. As can be seen from the above definition, CRTL gives the exception trace and a parameter as arguments to the callback function. The parameter in this case is set by the client application to be used by the user in the callback function.
The ClientID uniquely identifies a QueueConnection on the FioranoMQ server. If a ClientID has not been set, the FioranoMQ server assigns a unique ClientID to each QueueConnection.

Creating a QueueSession

A QueueConnection can be used to create QueueSessions using the following API.

Closing and Destroying a QueueConnection

The QueueConnection has to be closed and destroyed before quitting the application.
Closing a QueueConnection terminates all pending messages received for all consumers created on the connection's sessions. Closing a connection not only closes the communication channel with the server but does not free up the memory allocated to the object. So, it must be destroyed. The following APIs are used for closing and destroying the QueueConnection.

Here is the sample code of how to use a QueueConnection and destroy it.
//...
QueueConnection qc = NULL;//...qc = QCF_createQueueConnection(qcf, "ayrton", "senna");//...QC_setClientID("myConnection");QC_start(qc);//...QC_setExceptionListener(qc,onException,param);//..QC_createSession(qc,FALSE,AUTO_ACKNOWLEDGE);QC_stop(qc);//if needed//...QC_close(qc);//...QC_free(qc);//... h2.Using a QueueSession
A QueueSession object provides methods for creating QueueReceiver, Queue-Sender, QueueBrowser, Queue, and TemporaryQueue objects.
If there are messages that have been received but not acknowledged when a QueueSession terminates, these messages are retained and redelivered when a consumer next accesses the queue.

Transactions on a QueueSession

For non-transacted sessions any messages sent using the sender created on the session are sent to the server immediately following the QSNDR_send() call and an acknowledgement is sent for the message, immediately when it is received.
JMS specifies another type of session named transacted session. In transacted sessions, each transaction groups a set of produced messages and a set of consumed messages into an atomic unit of work. When a transaction is committed, its atomic unit of input is acknowledged and its associated atomic unit of output is sent. If a transaction rollback is done, its produced messages are destroyed and its consumed messages are automatically recovered. A transacted session can be created by setting the value of the second argument to TRUE in the QC_createSession API explained in the section "Using a QueueConnection"of this chapter.
The following APIs of CRTL are used to implement transacted sessions in applications.

Senders, Receivers and Browsers on a QueueSession

A QueueSession can be used to create senders, receivers, (with and without message selectors) and browsers (with and without message selectors) on a Queue using the following APIs.

Creating Fiorano Messages

A QueueSession can be used to create different message types using the APIs listed in the table below. All messages are created with the default JMSHeader and an empty message body.

Creating and Destroying Queues

The Queue is a destination object for messages in JMS. This is an administered object that can be looked up from the FioranoMQ server using the InitialContext. A C client application can also create its own Queue object using the QueueSession.
A QueueSession can be used to create a TemporaryQueue as well. The CRTL provides APIs to delete and destroy temporary queues as shown in the table below.

Asynchronous Listener on QueueSession

A QueueSession can be used to register a MessageListener on a Queue for receiving messages asynchronously. The delivery of messages on this listener starts only when a receiver is created on the Queue using the same QueueSession. For more information, read the Using a QueueReceiver section in this chapter.
The following APIs control the use of the MessageListener on a QueueSession.

Closing and Destroying a QueueSession

QueueSessions need to be closed and destroyed before quitting an application
Closing a QueueSession terminates all pending message received for all con-sumers created on the connection's sessions. Closing a connection not only closes the communication channel with the server but does not free up the memory allo-cated to the object. So, it must be destroyed. The following APIs are used for clos-ing and destroying the QueueConnection.

Using a QueueSender

A client uses a QueueSender to send messages to a queue. Normally, the Queue is specified when a QueueSender is created. This Queue can also be specified as NULL while creating a QueueSender in which case it is termed as an unidentified QueueSender.
If the QueueSender is created with an unidentified or NULL Queue, an attempt to use the send methods, which assume that the Queue has been identified, results in an error.
During the execution of its send method, a message must not be changed by other threads within the client. If the message is modified, the result of the send is undefined.
After sending a message, a client may retain and modify it without affecting the message that has been sent. The same message may be sent multiple times.
The following message headers are set as part of sending a message:

• JMSDestination
• JMSDeliveryMode
• JMSExpiration
• JMSPriority
• JMSMessageID
• JMSTimeStamp.

When the message is sent, the values of these headers are ignored. After the completion of the send, the headers hold the values specified by the method sending the message. It is possible for the send method not to set the JMSMessageID and JMSTimeStamp if the setting of these headers is explicitly disabled by the QSNDR_setDisableMessageID or QNSDR_setDisableMessageTimestamp method.

Message Params For A Sender

CRTL provides APIs using which certain parameters in the MessageHeader of messages to be sent can be controlled at the QueueSender level. Applications can set the priority, delivery mode, and the time to live in the sender. These values are in turn be set for all messages that are sent by the concerned sender.
Applications can also disable the generation of JMSMessageID and JMSMessageTimestamp for all messages sent by a QueueSender.
The APIs for the above-mentioned functions are listed in the following table.

Sending a Message on a Queue

The FioranoMQ CRTL provides different APIs for sending a message on a Queue. These APIs can be used to send messages on the Queue on which the sender is created and also on any other specified Queue.

Closing and Destroying a QueueSender

An application should close and destroy the QueueSender before quitting. The close call does not free the memory occupied by the QueueSender. All senders created using a QueueSession are also closed in the close call of the QueueSession.

Using a QueueReceiver

A client uses a QueueReceiver object to receive messages that have been delivered to a queue.
Although it is possible to have multiple QueueReceivers for the same queue, the CRTL API does not define how messages are distributed between the QueueReceivers.
If a QueueReceiver specifies a message selector, the messages that are not selected remain on the queue. By definition, a message selector allows a QueueReceiver to skip messages. This means that when the skipped messages are eventually read, the total ordering of the reads does not retain the partial order defined by each message producer. Only QueueReceivers without a message selector reads messages in message producer order.

Synchronous Message Receive

Messages can be received synchronously from a Queue using the QueueReceiv-er's receive calls. These receive calls are of three distinct types:

• A blocking call that blocks for a infinite time period and returns as soon as a message is available in the queue
• A blocking call the blocks for a specified timeout period and returns if a message is available or if the timeout period expires
• A non-blocking call that returns without waiting for a message to be available

The APIs can be used perform the synchronous receive operations mentioned above.

Asynchronous Message Receive

The CRTL specifies a way to receive messages asynchronously using the MessageListener. Unlike the JMS API, MessageListener is a callback function and not a structure. This callback function is defined as:
void (*MessageListener)(Message msg);
The CRTL provides another version of this callback function. This version can be given a parameter as function argument. This can be useful in cases where the application wants to perform some operation in the callback function that requires some external structure. This callback is termed as FioranoMessageListener and is defined as:
void (FioranoMessageListener)(struct _Message, void* pParam);
The callback function and the parameter are passed as arguments to the setFioranoMessageListener API described in the following table.
The QueueSession can also be used to set a MessageListener as explained in the section "Using a QueueSession"of this chapter. In case an application sets a MessageListener on both the QueueSession and a QueueReceiver created from the same session then the QueueSession's callback function is invoked.

Closing and Destroying a QueueReceiver

An application should close and destroy the QueueReceiver before quitting the application. The close call does not free the memory occupied by the QueueReceiver. All receivers created using a QueueSession are also closed in the close call of the QueueSession.

Request/Reply on Queues

The QueueRequestor object is provided by the CRTL to simplify the making service requests. It creates a TemporaryQueue for the responses and provides a request function that sends the request message and waits for its reply. This request can be sent with a specified timeout interval as well.
The QueueReplier is not a seperate structure in the CRTL like the QueueRequestor. A reply to a request message can be sent using the following steps.

1. Create a QueueReceiver on the Queue on which the requestor is sending requests. This QueueReceiver may receive messages synchronously or asynchronously.
2. Create a QueueSender on any Queue or a NULL Queue.
3. Start the QueueConnection on which the receiver is created.
4. When the request is received by the above QueueReceiver, get the JMSReplyTo (which is a TemporaryQueue by default) and the JMSCorrelationID (only for the case of requestWithTimeout) from the request message. For more information, read the Fiorano Message section in this chapter.
5. Now create a reply message using the QueueSession of the receiver and set the JMSCorrelationID extracted from the request in the reply message. This step has to be performed only if requestWithTimeout is being used.
6. Send the reply on the JMSReplyTo destination extracted from the request message using the QueueSender created above.

The implementation of the steps, mentioned above, is shown in the following code snipppet.
qr = QS_createReceiver(qss, queue);
qsn = QS_createSender(qss, queue);..//snmsg = QS_createTextMessage(qss);..//QRCVR_setMessageListener(qr, onMsgRecv);QC_start(qc);void onMsgRecv(Message msg){rpstr = (mqstring)malloc(100*(sizeof(char)));mqstring corrID = NULL;Queue tqueue = NULL;..//corrID = MSG_getJMSCorrelationID(msg);MSG_setJMSCorrelationID(snmsg, corrID);FTMSG_setText(snmsg,rpstr);..//tqueue = MSG_getJMSReplyTo(msg);QSNDR_send2(qsn, tqueue, snmsg);..// free the replyTo destination and the message structures}

Creating a Requestor

The QueueRequestor is created on a Queue using a QueueSession. The following API can be used for the same.

Sending a Request

The QueueRequestor is used to send requests on a Queue. These requests can be sent with an infinite timeout or for a specified timeout period. In case of request with a timeout, the requestor waits for a reply for the timeout period and return null if no reply is available within the timeout period.

Closing and Destroying a QueueRequestor

A QueueRequestor must be closed and destroyed before quitting an application. The close API of the QueueRequestor does not free the memory allocated to the structure.

Browsing a Queue

A QueueBrowser is used for browsing a Queue for messages. This can be created using a QueueSession as explained in the section "Using a QueueSession"of this chapter.
A QueueBrowserEnumeration structure is returned by the getEnumeration call of the QueueBrowser which in turn is used for browsing the messages.
The QueueBrowser and QueueBrowserEnumeration have to be closed and destroyed by the application.
The following APIs are used for browsing a Queue.

 

Publish-Subscribe Model

Using a TopicConnectionFactory

TopicConnectionFactory is a factory object used to create TopicConnections with the FioranoMQ server. A ConnectionFactory object encapsulates a set of connection configuration parameters that has been defined by an administrator.This is an administered object and should be looked up from the FioranoMQ server using the InitialContext (as explained in the section Lookup Administered Objects of this chapter). The user cannot create his/her own TopicConnectionFactory object using the CRTL. This can be done using the FioranoMQ AdminTool or by using the admin APIs provided in the default Java RTL.
One of the predefined TopicConnectionFactory objects in the FioranoMQ server is the primaryTCF. This is used in all the examples explained in the document where a TCF is necessary.

Creating a TopicConnection

TopicConnectionFactories are used to create TopicConnections with the FioranoMQ server. The TopicConnection is created with the server running on the ConnectURL specified in the TopicConnectionFactory and if the same is unavailable then the RTL tries to make a connection with a BackupURL, if any.
TopicConnections can be created using default user identity ("anonymous","anon-ymous" in case of FioranoMQ) or by specifying a username and password.

Destroying a TopicConnectionFactory

The TopicConnectionFactory object created in the application should be destroyed before quitting, using the following function.

. Here is the sample code of how to look up a TopicConnectionFactory from the FioranoMQ server and use it to create a TopicConnection.
TopicConnectionFactory tcf = NULL;
//...tcf = (TopicConnectionFactory)IC_Lookup(ic,"primaryTCF");tc = QCF_createTopicConnection(tcf, "ayrton", "senna");//...TCF_free(tcf);//...//Free other objects before exit.

Using a TopicConnection

The TopicConnection is an active connection to the FioranoMQ server. It is used to create one or more topic sessions for producing and consuming messages. It is created using the TopicConnectionFactory as mentioned in the "Using a TopicConnection-Factory" section of this chapter.

Starting and Stopping a TopicConnection

The delivery of messages on a connection is controlled by the start and stop APIs. Starting a connection starts or resumes the delivery of messages to consumers on that connection and stopping the connection temporarily stops the delivery of messages to all consumers on that connection.
The ExceptionListener functionality also gets enabled only if the connection is started.
Following APIs are used to control the start and stop of TopicConnections.

ExceptionListener on a TopicConnection

ExceptionListeners are used to check for error conditions on a TopicConnection. Users can set and get ExceptionListeners on a TopicConnection.
The ExceptionListener is not a structure but a callback function in the CRTL that is defined as
void (*ExceptionListenerPointer)(char *exception, void *pParam);
The client applications have to set the function pointer for such a callback function as the ExceptionListener and whenever some exception occurs on a connection that callback function is invoked by the CRTL. As can be seem from the above definition the CRTL gives the exception trace and a parameter as arguments to the callback function. The parameter in this case is set by the client application to be used by the user in the callback function.
The ClientID uniquely identifies a TopicConnection on the FioranoMQ server. If no ClientID is set the FioranoMQ server assigns a unique ClientID to each TopicConnection.

TopicSessions on a TopicConnection

A TopicConnection can be used to create TopicSessions using the following API.

Closing and Destroying a TopicConnection

The TopicConnection has to be closed and destroyed before quitting from the user application.
Closing a TopicConnection terminates all pending message receives on the con-nection's session's consumers. Closing a connection only closes the communication channel with the server but doesn't free up the memory allocated to the object. So, it must be destroyed. The following APIs are used for closing and destroying the TopicConnection.

Here is the sample code of how to use a TopicConnection and destroy it.
//...
TopicConnection qc = NULL;//...tc = TCF_createTopicConnection(tcf, "ayrton", "senna");//...TC_setClientID("myConnection");TC_start(tc);//...TC_setExceptionListener(qc,onException,param);//..TC_createSession(tc,FALSE,AUTO_ACKNOWLEDGE);TC_stop(tc);//if needed//...TC_close(tc);//...TC_free(tc);//... h2.Using a TopicSession
A TopicSession provides methods for creating TopicPublishers, TopicSubscribers, and TemporaryTopics. It also provides the unsubscribe method for deleting its cli-ent's durable subscriptions.If there are messages that have been received but not acknowledged when a TopicSession terminates, a durable TopicSubscriber must retain and redeliver them; a nondurable subscriber need not do so.

Transactions on a TopicSession

For non-transacted sessions any messages sent using the publisher created on the session are sent to the server immediately following the TP_publish() call and an acknowledgement is sent for the message, immediately when it is received by a subscriber.
JMS specifies another type of session that is, transacted session, in which each transaction groups a set of produced messages and a set of consumed messages into an atomic unit of work. When a transaction is committed, its atomic unit of input is acknowledged and its associated atomic unit of output is sent. If a transaction rollback is done, its produced messages are destroyed and its consumed messages are automatically recovered. A transacted session can be created by setting the value of the second argument to TRUE in the TC_createTopicSession API explained in the section "Using a TopicConnection" of this chapter.
The following APIs of CRTL are used to implement transacted sessions in applications.

Publishers and Subscribers on a TopicSession

A TopicSession can be used to create publishers and subscribers (with and without message selectors) on a Topic using the following APIs.
Both durable and non-durable subscribers can be created using a TopicSession.

Creating Fiorano Messages

A TopicSession can be used to create different message types using APIs listed in the table below. All messages are created with the default JMSHeader and an empty message body.

Creating and destroying Topics

The Topic is a destination object for messages in the publish/subscribe model of JMS. This is an administered object that can be looked up from the FioranoMQ server using the InitialContext. A C client application can also create its own Topic object using the TopicSession.
Before quitting a C client application both Topics and Temporary topics must be freed if created or looked up.

Asynchronous Listener on TopicSession

A TopicSession can be used to register a MessageListener on a Topic for receiving messages asynchronously. The delivery of messages on this listener starts only when a subscriber is created on the Topic using the same TopicSession. For more information on the MessageListener refer to the section "Using a TopicSubscriber" in this chapter.
The following APIs control the use of the MessageListener on a TopicSession.

Closing and Destroying a TopicSession

TopicSessions need to be closed and destroyed before quitting an application that is using them.
Closing a TopicSession terminates all pending message receives on the session's consumers. Closing a session doesn't free up the memory allocated to the object,

Using a TopicPublisher

A client uses a TopicPublisher object to publish messages on a topic. A TopicPublisher object is the publish-subscribe form of a message producer.
Normally, the Topic is specified when a TopicPublisher is created. This Topic can also be specified as NULL while creating a TopicPublisher in which case it is termed as an unidentified TopicPublisher.
If the TopicPublisher is created with an unidentified or NULL Topic, an attempt to use the send methods that assume that the Topic has been identified results in an error.
During the execution of its publish method, a message must not be changed by other threads within the client. If the message is modified, the result of the publish is undefined.
After publishing a message, a client may retain and modify it without affecting the message that has been published. The same message object may be published multiple times.
The following message headers are set as part of publishing a message: JMSDestination, JMSDeliveryMode, JMSExpiration, JMSPriority, JMSMessageID and JM-STimeStamp. When the message is published, the values of these headers are ignored. After completion of the publish, the headers hold the values specified by the method publishing the message. It is possible for the publish method not to set JMSMessageID and JMSTimeStamp if the setting of these headers is explicitly disabled by the TP_setDisableMessageID or TP_setDisableMessageTimestamp method.

Message Params for a Publisher

The CRTL provides APIs using which certain parameters in the MessageHeader of messages to be published can be controlled at the TopicPublisher level. Applications can set the priority, delivery mode and the time to live in the publisher. These values are in turn be set for all messages that are published by the concerned publisher.
Applications can also disable the generation of JMSMessageID and JMSMessageTimestamp for all messages published by a TopicPublisher.

Publishing a message on a Topic

The FioranoMQ CRTL provides different APIs for publishing a message on a Topic. These APIs can be used to publish messages on the Topic on which the publisher is created and also on any other specified Topic.

Destroying a TopicPublisher

An application should close and destroy the TopicPublisher before quitting the application. The close call does not free the memory occupied by the TopicPublishebr. All senders created using a TopicSession are also closed in the close call of the TopicSession.

Using a TopicSubscriber

A client uses a TopicSubscriber object to receive messages that have been published to a topic. A TopicSubscriber object is the publish/subscribe form of a message consumer.
A TopicSession allows the creation of multiple TopicSubscriber objects per topic. It delivers each message for a topic to each subscriber eligible to receive it. Each copy of the message is treated as a completely separate message. Work done on one copy has no effect on the others; acknowledging one does not acknowledge the others; one message may be delivered immediately, while another waits for its subscriber to process messages ahead of it.
Regular TopicSubscriber objects are not durable. They receive only messages that are published while they are active.
Messages filtered out by a subscriber's message selector would never be delivered to the subscriber. From the subscriber's perspective, they do not exist.
In some cases, a connection may both publish and subscribe to a topic. The subscriber NoLocal attribute allows a subscriber to inhibit the delivery of messages published by its own connection.
If a client needs to receive all the messages published on a topic, including the ones published while the subscriber is inactive, it uses a durable TopicSubscriber. The FioranoMQ server retains a record of this durable subscription and insures that all messages from the topic's publishers are retained until they are acknowledged by this durable subscriber or they have expired.
Sessions with durable subscribers must always provide the same client identifier. In addition, each client must specify a name that uniquely identifies (within client identifier) each durable subscription it creates. Only one session at a time can have a TopicSubscriber for a particular durable subscription.
A client can change an existing durable subscription by creating a durable Topic-Subscriber with the same name and a new topic and/or message selector. Changing a durable subscription is equivalent to unsubscribing (deleting) the old one and creating a new one.
The unsubscribe method is used to delete a durable subscription. The unsubscribe method can be used at the Session or TopicSession level. This method deletes the state being maintained on behalf of the subscriber by its provider.

Synchronous Message Receive

Messages can be received synchronously from a Topic using the receive call of the TopicSubscriber. This receive call is a blocking call that blocks for an infinite time period, for a specified timeout period or does not block at all. The call returns as soon as a message is available on the concerned Topic. The following APIs can be used to perform the synchronous receive operations.

Asynchronous message receive

The CRTL specifies a way to receive messages asynchronously using the MessageListener. Unlike the JMS API the MessageListener in the CRTL is a callback function and not a structure. This callback function is defined as
void (*MessageListener)(Message msg);
This callback is invoked by the CRTL when a message arrives from the FioranoMQ server. A client application has to set the function pointer of the callback function it declares in the setMessageListener call.
The CRTL provides another version of this callback function that can be given a parameter as function argument. This can be useful in cases where the application wants to perform some operation in the callback function that requires some external structure. This callback is termed as FioranoMessageListener and is defined as
void (FioranoMessageListener)(struct _Message, void* pParam);
The callback function and the parameter are passed as arguments to the setFioranoMessageListener API described in the table below.
A TopicSession can also be used to set a MessageListener as explained in the section "Using a TopicSession"of this chapter. In case an application sets a Message.

Destroying a TopicSubscriber

An application should close and destroy the TopicSubscriber before quitting the application. The close call does not free the memory occupied by the TopicSubscriber. All subscribers created using a TopicSession are also closed in the close call of the TopicSession.

Request/Reply on Topics

The TopicRequestor object is provided by the CRTL to simplify making service requests. It creates a TemporaryTopic for the responses and provides a request function that sends the request message and waits for its reply. This request can be sent with a specified timeout interval as well.
The TopicReplier is not a separate structure in the CRTL like the TopicRequestor. A reply to a request message on a Topic can be sent using the following steps.

1. Create a TopicSubscriber on the Topic on which the requestor is sending requests. This TopicSubscriber may receive messages synchronously or asynchronously.
2. Create a TopicPublisher on any Topic or a NULL Topic.
3. Start the TopicConnection on which the subscriber is created.
4. When the request is received by the above TopicSubscriber get the JMSReplyTo (which is a TemporaryTopic) and the JMSCorrelationID (only for the case of requestWithTimeout) from the request message. For information on APIs to get the mentioned parameters refer to the section "FioranoMessage" in this chapter.
5. Now create a reply message using the TopicSession of the subscriber and set the JMSCorrelationID extracted from the request in the reply message. This step has to be done only if requestWithTimeout is being used.
6. Send the reply on the JMSReplyTo destination extracted from the request message using the TopicPublisher created above.

The following code snippet depicts the above mentioned steps.
..// steps for creation of TopicSession and lookup of Topic
tsub = TS_createSubscriber(ts, topic);tpub = TS_createPublisher(ts, topic);..//snmsg = TS_createTextMessage(ts);..//TSUB_setMessageListener(tsub, onMsgRecv);TC_start(tc);void onMsgRecv(Message msg){rpstr = (mqstring)malloc(100*(sizeof(char)));mqstring corrID = NULL;Topic tTopic = NULL;..//corrID = MSG_getJMSCorrelationID(msg);MSG_setJMSCorrelationID(snmsg, corrID);FTMSG_setText(snmsg,rpstr);..//tTopic = MSG_getJMSReplyTo(msg);TPUB_publish2(ts, tTopic, snmsg);..// free the replyTo destination and the message structures

Creating a TopicRequestor

The TopicRequestor is created on a Topic using a TopicSession. The following API can be used for the same.

Sending a request on a Topic

The TopicRequestor is used to send requests on a Topic. These requests can be sent with an infinite timeout or for a specified timeout period. In case of request with

Closing and Destroying a TopicRequestor

A TopicRequestor must be closed and destroyed before quitting an application. The close API of the TopicRequestor does not free the memory allocated to the structure.

Client-Side Logging

In order to enable logging in CRTL, the following system environmental variables have to be set.

In INFO level information about successful look up or creation of objects is logged. Logging in publish and receive calls are moved to DEBUG level due to the file size constraint when messages are published continuously.

• In DEBUG level, addresses of any memory that is being freed are logged.
• If DEBUG level is set, both INFO and ERROR statements will be logged.
• Similarly, if INFO level is set ERROR statements will also be logged.

Logging is done internally in CRTL. The log file will be created in the directory where the application exists. The following functions are available for the user.

LH_setLoggerName

Declaration: mqboolean LH_setLoggerName(mqstring name);
sets file name[in which data is logged] to name. The default file name is "cclient".
For example –
LH_setLoggerName("Publisher");
'.log' is appended to the file name.
Note: The maximum file size for the log file is set to 1 MB. As a result new log file will be created when the file size exceeds 1 MB. New files will be created with numbering as name_0.log, name_1.log, name_2.log and so on.

LH_getLogger

Declaration: LogHandler *LH_getLogger();
It returns the reference to the logHandler, using which data can be logged from application.
The structure used for logger is LogHandler.

LH_setTraceLevel

Declaration: mqboolean LH_setTraceLevel(LogHandler logger,mqstring level);
The trace level can also be set using this function. The legal values for the "level" are:

1. "ERROR"
2. "INFO"
3. "DEBUG"

For example, trace level can be set or changed to "INFO" by calling, LH_setTraceLevel(logger, "INFO");

LH_logData

Declaration: mqboolean LH_logData(LogHandler logger, mqstring info, ...);
This function logs the given data to the log file.It is variable argument function. The usage of this function is similar to "printf" function.
For example, LH_logData(logger, "Logging from file - %s, func -%s", "FileName", "funcName");
In log file it is printed as follows:
Fri Dec 19 14:41:25 2008 :APPL: Logging from file - FileName, func -funcName

CSPBowser

CSP Browser is used to browse the messages stored in Client-Side Persistent Cache. While browsing messages are read from CSP and are not deleted. So, next time when the Server is re-connected, messages are sent to the Server.
The structures used for CSP Browsing are CSPBrowser and CSPEnumeration.
The following functions are used for CSP Browsing:

CSPM_createCSPBrowser

Declaration: CSPBrowser CSPM_createCSPBrowser(mqstring dbPath);
This function returns the CSPBrowser Object for CSP cache located in the dbPath.

CSPB_getAllConnections

Declaration: ListEnumerator CSPB_getAllConnections(CSPBrowser browser);
This function returns the enumeration of all the Connection IDs whose messages are stored in CSP

CSPB_getTopicsForConnection

Declaration: ListEnumerator CSPB_getTopicsForConnection(CSPBrowser browser, mqstring connID);
This function returns the Enumeration of all the topic names for the specified connection with clientID as connID.

CSPB_getQueuesForConnection

Declaration: ListEnumerator CSPB_getQueuesForConnection(CSPBrowser browser, mqstring connID);
This function returns the Enumeration of all the queue names for the specified connection with clientID as connID.

CSPB_browseMessagesOnQueue

Declaration: CSPEnumeration CSPB_browseMessagesOnQueue(CSPBrowser browser, mqstring queueName, mqboolean checkTransacted);
This function returns the enumeration of messages stored in the queue specified by queueName. It searches for messages in queue in all the existing connections. If checkTransacted is TRUE, transacted messages are also browsed.

CSPB_browseMessagesOnQueue2

Declaration: CSPEnumeration CSPB_browseMessagesOnQueue2(CSPBrowser browser, mqstring connectionID, mqstring queueName, mqboolean checkTransacted);
This function returns the enumeration of messages stored in the queue specified by queueName. It searches for messages in queue for the connection specified by connectionID. If checkTransacted is TRUE, transacted messages are also browsed.

CSPB_browseMessagesOnTopic

Declaration: CSPEnumeration CSPB_browseMessagesOnTopic(CSPBrowser browser, mqstring topicName, mqboolean checkTransacted);
This function returns the enumeration of messages stored in the topic specified by topicName. It searches for messages in topic in all the existing connections. If checkTransacted is TRUE, transacted messages are also browsed.

CSPB_browseMessagesOnTopic2

Declaration: CSPEnumeration CSPB_browseMessagesOnTopic2(CSPBrowser browser, mqstring connectionID, mqstring topicName, mqboolean checkTransacted);
This function returns the enumeration of messages stored in the topic specified by topicName. It searches for messages in topic for the connection specified by connectionID. If checkTransacted is TRUE, transacted messages are also browsed.

CSPB_numberOfMessagesinCSPQueue

Declaration: mqlong CSPB_numberOfMessagesinCSPQueue(CSPBrowser browser, mqstring connID, mqstring queueName, mqboolean checkTransacted);
This function returns the number of messages stored in the queue specified by queueName for a given connection with clientID connID.
If checkTransacted is TRUE, transacted messages are also counted.

CSPB_numberOfMessagesinCSPTopic

Declaration: mqlong CSPB_numberOfMessagesinCSPTopic(CSPBrowser browser, mqstring connID, mqstring topicName, mqboolean checkTransacted);
This function returns the number of messages stored in the topic specified by topicName for a given connection with clientID connID.
If checkTransacted is TRUE, transacted messages are also counted.

CSPB_free

Declaration: void CSPB_free(CSPBrowser browser);
This function frees the CSP Browser Structure.

CSPE_hasMoreElements

Declaration: mqboolean CSPE_hasMoreElements(struct _CSPEnumeration* cspEnum);
This function checks whether more elements are available in the enumeration.

CSPE_nextElement

Declaration: mqobject CSPE_nextElement(struct _CSPEnumeration* cspEnum);
This function returns the next element of this enumeration if this enumeration object has at least one more element to provide.

CSPE_free

Declaration: void CSPE_free(struct _CSPEnumeration* cspEnum);
This function frees the CSP Enumeration structure cspEnum.

Fiorano Message

Message is the most widely used entity in JMS. The different types of messages defined by JMS are:

• TextMessage
• StreamMessage
• BytesMessage
• MapMessage
• ObjectMessage

The CRTL provides the functionality related to TextMessage, StreamMessage, BytesMessage, and MapMessage. The ObjectMessage functionality is not provided.
Apart from these four types, a generic message type "Message" is also defined. In the CRTL, all the four of them are just synonyms for the same type, "Message".
The type name Message is used in the JMS functions, which can operate on any type of message. The specific type names are used in the functions, which operate on that particular type of message.
The methods defined in the base class Message and its subclasses in JMS are defined in CRTL with meaningful prefixes. These prefixes are summarized in the following table.

Even though these functions expect specific types of messages as arguments, the compiler won't detect any errors different types of messages are passed. This is because all messages are just type defined to the same type. Therefore, it is the responsibility of the developer, to send proper types of messages as arguments, failing which an error is set at the runtime.
JMS messages are composed of the following parts:

• Header All messages support the same set of header fields. Header fields contain values used by both clients and providers to identify and route messages.
• Properties Each message contains a built-in facility for supporting applica-tion-defined property values. Properties provide an efficient mechanism for supporting application-defined message filtering.
• Body The JMS API defines several types of message body, which cover the majority of messaging styles currently in use.

All message types can be created using a QueueSession or a TopicSession. For more information on this refer to the sections "Using a QueueSession" and "Using a TopicSession" of this chapter.

Message Bodies

The CRTL API defines five types of message body. They are:

• Stream A StreamMessage object's message body contains a stream of values of different datatypes. It is filled and read sequentially.
• Map A MapMessage object's message body contains a set of name-value pairs, where names are mqstring objects, and values are different C datatypes. The entries can be accessed sequentially or randomly by name. The order of the entries is undefined.
• Text A TextMessage object's message body contains an mqstring object. This message type can be used to transport plain-text messages, and XML messages.
• Bytes A BytesMessage object's message body contains a stream of uninterpreted bytes. This message type is for literally encoding a body to match an existing message format. In many cases, it is possible to use one of the other body types, which are easier to use. Although the JMS API allows the use of message properties with byte messages, they are typically not used, since the inclusion of properties may affect the format.

Message Header

The MessageHeader contains standard information relating to a Message that is used by the FioranoMQ server and by the client applications. The header contains the following fields:

• JMSType
• JMSMessageID
• JMSTimestamp
• JMSDeliveryMode
• JMSPriority
• JMSExpiration
• JMSDestination
• JMSReplyTo
• JMSCorrelationID
• JMSRedelivered

The JMSMessageID and JMSTimestamp are set by the FioranoMQ server after a message send or publish call returns. Any values set by the client applications for these header fields are ignored.
The JMSDestination, JMSDeliveryMode, JMSPriority, and JMSExpiration are set to the values specified in the send or publish call after the call returns. Any values set by the client applications for these variables in the Message structure are ignored during the send/publish call.
The JMSCorrelationID header field is used for linking one message with another. It typically links a reply message with its requesting message. The following APIs are used to control the message header fields.

Message Properties

A Message object contains a built-in facility for supporting application-defined property values. In effect, this provides a mechanism for adding application-specif-ic header fields to a message.
Properties allow an application, via message selectors, to have the FioranoMQ server select, or filter, messages on its behalf using application-specific criteria.
Property names must obey the rules for a message selector identifier. Property names must not be null, and must not be empty strings. If a property name is set and it is either null or an empty string, an exception is thrown.
Property values can be mqboolean, mqbyte, mqshort, mqint, mqlong, mqfloat, mqdouble, and mqstring.
Property values are set prior to sending a message. When a client receives a message, its properties are in read-only mode. If a client attempts to set properties at this point, an exception is thrown. If clearProperties is called, the properties can now be both read from and written to. Note that header fields are distinct from properties. Header fields are never in read-only mode.
A property value may duplicate a value in a message's body, or it may not. For best performance, applications should use message properties only when they need to customize a message's header. The primary reason for doing this is to support customized message selection.
The following APIs can be used to set and get different properties in a Message structure.

BytesMessage

A BytesMessage object is used to send a message containing a stream of uninterpreted bytes. The receiver of the message supplies the interpretation of the bytes.
This message type is for client encoding of existing message formats. If possible, one of the other self-defining message types should be used instead.
Although the JMS API allows the use of message properties with byte messages, they are typically not used. This is because the inclusion of properties may affect the format.
The data types can be written explicitly using methods for each type. When the message is first created, and when clearBody is called, the body of the message is in write-only mode. After the first call to reset has been made, the message body is in read-only mode. After a message has been sent, the client that sent it can retain and modify it without affecting the message that has been sent. The same message object can be sent multiple times. When a message has been received, the provider has called reset so that the message body is in read-only mode for the client.
If clearBody is called on a message in read-only mode, the message body is cleared and the message is in write-only mode. If a client attempts to read a message in write-only mode, an exception is thrown. If a client attempts to write a message in read-only mode, an exception is thrown.
Following APIs can be used to control the data in a bytes message.

MapMessage

A MapMessage object is used to send a set of name-value pairs. The names are mqstring objects, and the values are different data types of the C programming language. The names must have a value that is not null, and not an empty string. The entries can be accessed sequentially or randomly by name. The order of the entries is undefined.
The data-types can be read or written explicitly using methods for each type.
When a client receives a MapMessage, it is in read-only mode. If a client attempts to write to the message at this point, an exception is thrown. If clearBody is called, the message can now be both read from and written to.

StreamMessage

A StreamMessage object is used to send a stream of data types of the C programming language. It is filled and read sequentially.
The data-types can be read or written explicitly using methods for each type.
When the message is first created, and when clearBody is called, the body of the message is in write-only mode. After the first call to reset has been made, the message body is in read-only mode. After a message has been sent, the client that sent it can retain and modify it without affecting the message that has been sent. The same message object can be sent multiple times. When a message is received, the CRTL has called reset so that the message body is in read-only mode for the client.

• If clearBody is called on a message in read-only mode, the message body is cleared and the message body is in write-only mode.

• If a client attempts to read a message in write-only mode, an exception is thrown. If a client attempts to write a message in read-only mode, an exception is thrown.

  API	Function
  FSMSG_clearBody	Clears the contents of the stream message
  FSMSG_readBoolean	Reads an mqboolean from the stream message
  FSMSG_readByte	Reads an mqbyte from the stream message
  FSMSG_readBytes	Reads an mqbyteArray from the stream message
  FSMSG_readChar	Reads an mqchar from the stream message
  FSMSG_readDouble	Reads an mqdouble from the stream message.
  FSMSG_readFloat	Reads an mqfloat from the stream message
  FSMSG_readInt	Reads an mqint from the stream message
  FSMSG_readLong	Reads an mqlong from the stream message
  FSMSG_readShort	Reads an mqshort from the stream message
  FSMSG_readString	Reads an mqstring from the stream message
  FSMSG_reset	Puts the message body in read-only mode, and repositions the stream to the beginning.
  FSMSG_writeBoolean	Writes an mqboolean to the stream message, as a1-byte value
  FSMSG_writeByte	Writes an mqbyte to the stream message
  FSMSG_writeBytes	Writes an mqbyteArray to the stream message
  FSMSG_writeBytesWithOffset	Writes a portion of an mqbyteArray to the stream message
  FSMSG_writeChar	Writes an mqchar to the stream message
  FSMSG_writeDouble	Writes an mqdouble to the stream message
  FSMSG_writeFloat	Writes an mqfloat to the stream message
  FSMSG_writeInt	Writes an mqint to the stream message
  FSMSG_writeLong	Writes an mqlong to the stream message
  FSMSG_writeShort	Writes an mqshort to the stream message
  FSMSG_writeString	Writes an mqstring to the stream message

  TextMessage

  A TextMessage object is used to send a message containing an mqstring. It inherits from the Message interface and adds a text message body.
  This message type can be used to transport text-based messages, including those with XML content.
  When a client receives a TextMessage, it is in read-only mode. If a client attempts to write to the message at this point, an exception is thrown. If clearBody is called, the message can now be both read from and written to.

  API	Function
  FTMSG_getText	Gets the string containing data of this message
  FTMSG_setText	Sets the string containing data of this message.

  Acknowledging a message

  The CRTL provides the acknowledge API in the Message which is equivalent to the Message.acknowledge API of JMS. A call to this API acknowledges all messages delivered in that session till the message on which the call is made.
  This call is relevant for sessions that are created using the CLIENT_ACKNOWLEDGEMENT mode. In order to rollback messages received on a client ack session the TS_recover API can be used.

  API	Function
  MSG_acknowledge	Acknowledges all consumed messages of the session of this consumed message.

  Destroying a message

  A Message structure should be destroyed by the Client application after the message has been used to avoid memory leaks.
  All types of messages can be destroyed using the following API call.

  API	Function
  MSG_free	Frees the resources allocated for the message

  Large Message Support

  With Large Message Support (LMS) in FioranoMQ, clients can transfer large files in the form of large messages with theoretically no limit on the message size. Large messages can be attached with any JMS message and the client can be sure of a reliable and secure transfer of the message through FioranoMQ server. Please refer to chapter 15 of FioranoMQ concepts guide for detailed explanation of LMS.
  The following functions can be used to use LMS implementation.

  LMSG_ getMessageStatus

  Declaration: LMTransferStatus LMSG_getMessageStatus(Message msg);
  Gets the status of the message. Status includes number of bytes transferred, number of bytes left to be transferred, and so on.

  LMSG_ setLMStatusListener

  Declaration: void LMS_LMSG_setLMStatusListener(Message msg , LMStatusListener listener, int updateFrequency);
  Sets the status listener for the message. This function is used to know the status of message transfer asynchronously.
  LMStatusListener is defined as
  typedef void (*LMStatusListener)(LMTransferStatus status, mqboolean exOccurred);

  LMSG_ getLMStatusListener

  Declaration: LMStatusListener LMSG_getLMStatusListener(Message msg);
  Gets the status listener for the message.

  LMSG_ saveTo

  Declaration: void LMSG_saveTo(Message msg, mqstring fileName, mqboolean isBlocking);
  Saves the contents of the message in the file specified.

  LMSG_ resumeSaveTo

  Declaration: void LMSG_resumeSaveTo(Message msg, mqboolean isBlocking);
  Resumes saving the contents of the message in the file specified.

  LMSG_resumeSend

  Declaration: void LMSG_resumeSend(Message msg);
  Resumes an incomplete transfer. This function is used to resume a message transfer which could not be completed earlier either due to some internal error or due to some problem at the client side.

  LMSG_ cancelAllTransfers

  Declaration: void LMSG_cancelAllTransfers(Message msg);
  Cancels all message transfers which are currently transferring this message. A cancelled transfer also removes the resume information of the transfer. Hence a transfer once cancelled cannot be resumed.

  LMSG_ cancelTransfer

  Declaration: void LMSG_cancelTransfer(Message msg, int consumerID);
  Cancels the transfer specified by the consumerID.
  A cancelled transfer also removes the resume information of the transfer. Hence a transfer once cancelled cannot be resumed.

  LMSG_ suspendAllTransfers

  Declaration: void LMSG_suspendAllTransfers(Message msg);
  Suspends all the message transfers which are transferring this large message temporarily.
  Suspending a transfer only stops the thread which is doing the message transfer and does not delete resume related information. Hence, a suspended transfer can be resumed using resume functions.

  LMSG_suspendTransfer

  Declaration: void LMSG_suspendTransfer(Message msg, int consumerID);
  Suspends the transfer specified by the consumerID temporarily.
  Suspending a transfer only stops the thread which is doing the message transfer and does not delete resume related information. Hence, a stopped transfer can be resumed using resume functions.

  LMSG_setFragmentSize

  Declaration: void LMS_setFragmentSize(Message msg, int size);
  Sets the fragment size for the message.

  LMSG_getFragmentSize

  Declaration: int LMSG_getFragmentSize(Message msg);
  gets the fragment size of the message.

  LMSG_setWindowSize

  Declaration: void LMSG_setWindowSize(Message msg, int size);
  Sets the frequency after which acknowledgement will be sent

  LMSG_getWindowSize

  Declaration: int LMSG_getWindowSize(Message msg);
  gets the window size of the message.

  LMSG_setRequestTimeoutInterval

  Declaration: void LMSG_setRequestTimeoutInterval(Message msg, long timeout);
  Sets the time until which the sender will wait for message transfer to start

  LMSG_getRequestTimeoutInterval

  Declaration: long LMSG_getRequestTimeoutInterval(Message msg);
  Gets the time until which the sender will wait for message transfer to start

  LMSG_ setResponseTimeoutInterval

  Declaration: void LMSG_setResponseTimeoutInterval(Message msg, long responseInterval);
  Sets the time until which the sender/receiver will wait for message from the other end.

  LMSG_getResponseTimeoutInterval

  Declaration: long LMSG_getResponseTimeoutInterval(Message msg);
  Gets the time until which the sender/receiver will wait for messages from the other end. The following functions are to get the status information from LMTransferStatus Structure.

  LMTS_getBytesTransferred

  Declaration: mqlong LMTS_getBytesTransferred(LMTransferStatus lmts);
  Returns the number of bytes transferred.

  LMTS_getBytesToTransfer

  Declaration: mqlong LMTS_getBytesToTransfer(LMTransferStatus lmts);
  Returns the number of bytes to be transferred.

  LMTS_getLastFragmentID

  Declaration: mqlong LMTS_getLastFragmentID(LMTransferStatus lmts);
  Returns the ID of the last fragment.

  LMTS_getPercentageProgress

  Declaration: float LMTS_getPercentageProgress(LMTransferStatus lmts);
  Returns the percentage of the progress of message transfer.

  LMTS_getStatus

  Declaration: mqbyte LMTS_getStatus(LMTransferStatus lmts);
  Returns the status of the Message transfer.
  LM_TRANSFER_NOT_INIT or 1
  Indicates that the transfer has not yet started
  LM_TRANSFER_IN_PROGRESS or 2
  Indicates that transfer is currently in progress
  LM_TRANSFER_DONE or 3
  Indicates that the transfer is complete for one consumer
  LM_TRANSFER_ERR or 4
  Indicates that an error occurred during the transfer
  LM_ALL_TRANSFER_DONE or 5
  Indicates that the transfer is complete for all consumers

  LMTS_isTransferComplete

  Declaration: mqboolean LMTS_isTransferComplete(LMTransferStatus lmts);
  Returns TRUE if transfer completes, else returns FALSE.

  LMTS_isTransferCompleteForAll

  Declaration: mqboolean LMTS_isTransferCompleteForAll(LMTransferStatus lmts);
  Returns TRUE if all the transfers are completed, else returns FALSE.

  LMTS_getLargeMessage

  Declaration: Message LMTS_getLargeMessage(LMTransferStatus lmts);
  Returns the large message for which this status is created.

  LMTS_getConsumerID

  Declaration: int LMTS_getConsumerID(LMTransferStatus lmts);
  Returns the consumerID of the connection that is being used.
  These functions are used to get any pending large messages.

  LMC_getUnfinishedMessagesToSend

  Declaration: RMEnum LMC_getUnfinishedMessagesToSend(FioranoConnection fc);
  Gets the enumeration of Messages whose transfers are pending as they were not fully sent.

  LMC_getUnfinishedMessagesToReceive

  Declaration: RMEnum LMC_getUnfinishedMessagesToReceive(FioranoConnection fc);
  Gets the enumeration of Messages which were not fully received and need to be resumed.
  RMEnum is Recoverable Messages Enumeration. The following functions should be called to use the RMEnum structure.

  RME_hasMoreElements

  Declaration: mqboolean RME_hasMoreElements(RMEnum enumr);
  Returns true if there are more elements in the enumeration, false otherwise.

  RME_nextElement

  Declaration: mqobject RME_nextElement(RMEnum enumr);
  Return the next element (Message Object) of the enumeration.

  Error Handling

  The error handling mechanism in CRTL is very similar to Exception handling in Java. An exception/error stack is maintained and the errors occurred during a call to any API are pushed into this stack automatically. When the call returns, the user should check for any error occurred during that call and take necessary steps. For this purpose, the user is provided with the following functions, which operate on this error stack.

  API	Function
  MqExceptionOccured()	Returns a Boolean value indicating whether an exception occurred, in the most recent API call.
  MqPrintException()	Prints the exception stack, including the error code and a description
  MqExceptionClear()	Clears the stack of exceptions occurred until this call
  MqGetLastErrCode()	Gets the error code of the last exception pushed in the exception stack

  The MqExceptionOccurred() can be avoided by checking the return value of the API call.

• The APIs, which don't return any value in Java, are declared to return an mqboolean in CRTL indicating the success/failure of the call.
• The APIs, which return basic data types in Java, are declared to return an mqboolean and take a value-result argument of that type in CRTL. The mqboolean value returned indicates the success of the call
• The APIs, which return an object in Java, return a pointer in CRTL. The return value is NULL if an error occurred during the call.

The MqExceptionClear() function should be called after every failed API call. Or, it is possible that the following API calls fail due to the exception that occurred during this call.
The exception stack is maintained in the Thread Local Storage, so that the exception that occurred in one thread doesn't interfere the flow of other threads.
The MqGetLastErrCode() should be used, when the user wants to check what error has occurred in the API call and proceed accordingly. On the other hand, the MqPrintException() is used to print a detailed description of the Error, which leads to the root of the exception.

Utility APIs

Key-value pairs in Hashtable

Hashtable represents a pointer to an internally maintained structure, which maintains key value pairs.