Initializing and Monitoring APIs

This section describes how to initialize the messaging APIs and provides information for using messaging API logging and Session statistics.

Initializing APIs

To work with a messaging API, it must first be initialized.

JCSMP

No specific method call is required; JCSMP is initialized the first time a call is made to an API interface.

Java RTO, C, and .NET APIs

Call a function or method listed in the table below to initialize the Java RTO, C, or .NET APIs. When these messaging APIs are initialized, you can optionally set the initial log level filter for all log categories so that only logs at a specified level and more severe are emitted. (For more information on logging levels, refer to Configuring Logging.)

You can also set the global buffer sizes for the memory pools that are used to temporarily save messages in the application space (for the Java RTO API, refer to Modifying the Global Pool Buffer Sizes; for the C API, refer to C API Best Practices; for the .NET API, refer to Modifying the Global Pool Buffer Sizes).

JavaScript and Node.js APIs

Call the function listed in the table below to initialize the JavaScript or Node.js APIs. By default, when these APIs are initialized, they include the version 7 behavior profile for backwards compatibility. Behavior profiles allow old applications to remain compatible with old versions of the API, while allowing new applications to take advantage of updated recommended defaults. When writing a new application, Solace recommends using the newest available profile. For example, if version 10 is the newest profile, add the following to the entry point of your application to initialize the API with the version 10 profile and run it with the default property values that Solace recommends at the time of the version 10 release:

var factoryProps = new solace.SolclientFactoryProperties();
factoryProps.profile = solace.SolclientFactoryProfiles.version10;
solace.SolclientFactory.init(factoryProps);

When modifying an existing application to use a new behavior profile, the differences between behavior profiles should be considered.

To Initialize a Messaging API
PubSub+ Messaging API Use

JCSMP

Not applicable

Java RTO

Solclient.init(...)

C

solClient_initialize(...)

.NET

ContextFactory.Instance.Init(...)

JavaScript and Node.js

solace.SolclientFactory.init(...)

Related Samples

For an example of how to initialize the Java RTO or C API, refer to the DirectPubSub sample for that API. For the .NET API, refer to SampleApp. For the JavaScript and Node.js APIs refer to the TopicSubscriber and TopicPublisher samples.

Cleanup

When the client application is finished using the C API or .NET API, it should perform a global clean-up, which automatically frees all allocated resources, including those allocated for Contexts and Sessions that have been previously created but are not destroyed.

To Cleanup When Finished With the Messaging API
PubSub+ Messaging API Use

JCSMP

Not applicable

Java RTO

Not applicable

C

solClient_cleanup()

.NET

ContextFactory.Instance.Cleanup()

JavaScript and Node.js

Not applicable
  • Contexts and Sessions should always be destroyed or disposed before a cleanup is performed. If solClient_cleanup() or ContextFactory.Cleanup() is called while Sessions are connected, any messages buffered for transmission are discarded and not sent.

    Note that invocations of “initialize” and “cleanup” are reference counted. For example, if “initialize” is called twice, “cleanup” must be called twice to properly free the resources.

  • In the .NET environment, the .NET garbage collector may attempt to release IMessage containers after the application has called ContextFactory.Cleanup(). This will cause warnings like “2012-08-07 19:11:50Z - Warn - Sdk:Bad msg_p pointer (0000000004000FE1) in solClient_msg_free”. These warnings may be disregarded because they indicate that the API has detected and avoided a double-free.
    However, if the same application calls ContextFactory.Init() subsequent to ContextFactory.Cleanup(), the garbage collector may release messages that have been re-assigned to the newly initialized ContextFactory, and this will lead to an application crash. Therefore, it is recommended that you only call ContextFactory.Init()/ContextFactory.Cleanup() once.

Related Samples

For an example of how to perform a global cleanup for the C API, refer to the DirectPubSub sample. For the .NET API, refer to SampleUtils.cs included with the sample files.