TIBCO EMS – No memory for operation – Filesystem as datastore.

Very often we come across this kind of an error :-

Most probably if your EMS is running as a 32bit Binary and your message size is exceeding 1.6 – 2 GB in size

EMS For 32 bit has a size limitation of 2 GB

When you are using Filesystem as a datastore,

and when you come across such a trace

2007-07-24 10:46:38 Recovering state, please wait.
2007-07-24 10:48:47 SEVERE ERROR: Failed writing message to ‘datastore/meta.db’: No memory for operation.
2007-07-24 10:48:50 SEVERE ERROR: No memory processing purge record.
2007-07-24 10:48:52 FATAL: Exception in startup, exiting.

434692644 Jul 24 11:16 meta.db
29220 Jul 24 08:54 sync-msgs.db
5805854244 Jul 24 08:37 async-msgs.db

Don’t Panic, Its a very Generic issue

Just follow these checklists

1. Size of your message
2. Ensure you are using 64 bit EMS binary
3. Set max_msg_memory= <XX>GB in your tibemsd.conf, where XX indicated the Memory in GB you wanna assign.
4. Set msg_swapping=enabled.

• max_msg_memory
  

max_msg_memory = size [KB|MB|GB]
Maximum memory the server can use for messages.
This parameter lets you limit the memory that the server uses for messages, so server memory usage cannot grow beyond the system’s memory capacity.
When msg_swapping is enabled, and messages overflow this limit, the server begins to swap messages from process memory to disk. Swapping allows the server to free process memory for incoming messages, and to process message volume in excess of this limit.
When the server swaps a message to disk, a small record of the swapped message remains in memory. If all messages are swapped out to disk, and their remains still exceed this memory limit, then the server has no room for new incoming messages. The server stops accepting new messages, and send calls in message producers result in an error. (This situation probably indicates either a very low value for this parameter, or a very high message volume.)
Specify units as KB, MB or GB. The minimum value is 8 MB. The default value of 0 (zero) indicates no limit.
For example:
max_msg_memory = 512MB

msg_swapping

msg_swapping = enable | disable
This parameter enables and disables the message swapping feature (described above for max_msg_memory).
The default value is enabled, unless you explicitly set it to disabled.

reserve_memory

reserve_memory = size
When reserve_memory is non-zero, the daemon allocates a block of memory for use in emergency situations to prevent the EMS server from being unstable in low memory situations. When the daemon process exhausts memory resources, it disables clients and routes from producing new messages, and frees this block of memory to allow consumers to continue operation (which tends to free memory).
The EMS server attempts to reallocate its reserve memory once the number of pending messages in the server has dropped to 10% of the number of pending messages that were in the server when it experienced the allocation error. If the server successfully reallocates memory, it begins accepting new messages.
The reserve_memory parameter only triggers when the EMS server has run out of memory and therefore is a reactive mechanism. The appropriate administrative action when an EMS server has triggered release of reserve memory is to drain the majority of the messages by consuming them and then to stop and restart the EMS server. This allows the operating system to reclaim all the virtual memory resources that have been consumed by the EMS server. A trace option, MEMORY, is also available to help show what the server is doing during the period when it is not accepting messages.
Specify size in units of MB. When non-zero, the minimum block is 16MB. When absent, the default is zero.

Advertisement

TIBCO – EMS – Multicasting

Multicast Messaging:  Multicast is a messaging model that allows the EMS server to send messages to multiple consumers simultaneously by broadcasting them over an existing network.

Overview:  Multicast is a messaging model that broadcasts messages to many consumers at once, as opposed to sending copies of a message to each subscribing consumer individually.

The server sends multicast messages over a multicast channel. Each multicast-enabled topic is associated with a channel. The channel determines the multicast port and multicast group address to which the server sends messages.

The multicast message is received by a multicast daemon running on the same computer with the message consumer.

When an EMS client subscribes to a multicast-enabled topic, it automatically connects to the multicast daemon. The multicast daemon begins listening on the channel associated with that topic, receives any broadcast messages, and delivers them to subscribed clients.

When to use Multicast:  Because multicast reduces the number of operations performed by the server and
reduces the amount of bandwidth used in the publish-and-subscribe model, multicast is highly scalable.

Where publish and subscribe messaging creates a copy of a published message for each message consumer, multicast broadcasts the message only once.

Features

Multicast is highly scalable
Multicast reduces the amount of bandwidth consumed
Multicast reduces the number of operations performed by the server
Multicast broadcasts the message only once, where as in case of publish and subscribe for each of the consumer a copy of the message is getting published

Facts

Multicast does not guarantee message delivery
Messages requiring a high degree of reliability should not use multicast
Multicast offers last-hop delivery only; it cannot be used to send messages between servers.
Multicast should not be used in applications where security is a priority

 

Multicast Messaging Example:

Multicast channels can only be configured statically by modifying the configuration files. There are no commands in the administration tool to configure multicast channels.

 

Step 1: Enable the EMS Server for Multicast

To enable multicast in the server, set the multicast property to enabled in the tibemsd.conf configuration file:
multicast = enabled

 

Step2: Create a Multicast Channel

The EMS server broadcasts messages to consumers over multicast channels. Each channel has a defined multicast address and port. Messages published to a multicast-enabled topic are sent by the server and received by the subscribers on these multicast channels.
To create a multicast channel, add the following definition to the multicast channels configuration file, channels.conf:
[multicast-1]
address=234.5.6.7:1

 

Start the EMS Server.

 

Step3: Create a topic with Multicast enabled 

To create a multicast-enabled topic, use the administration tool to issue the following command:

> create topic testtopic channel=multicast-1

 

then execute the show topic command to verify multicast is enabled or not

 >show topics

 

the result will be like …

 

Topic Name SNFGEIBCTM Subs Durs Msgs Size

testtopic                  ———+           0 0 0 0.0 Kb

 

+ at M means multicast is enabled.

 

Step 4: Start the Multicast Daemon

go to Start menu, follow the path All Programs > TIBCO > TIBCO EMS 7.0 > Start
EMS Multicast Daemon.

 

Step5: Start the Subscriber

Execute the tibjmsMsgConsumer client to assign user1 as a subscriber to the multicastTopic topic with a Session acknowledgment mode of NO_ACKNOWLEDGE:
C:\tibco\ems\7.0\samples\java> java tibjmsMsgConsumer –topic testtopic –user user1 –ackmode NO

in Administration Console type the below command for cross verification…

>show consumers topic=testtopic

 

Step6: Start the producer

 Setting up a client to publish multicast message is no different from setting up a client to send publish and subscribe messages. Because the topic is enabled for multicast in the EMS server, the message producer does not need to follow any additional steps.

 

C:\tibco\ems\7.0\samples\java>java tibjmsMsgProducer -topic testtopic -user admin hello

 

Finally the messages (hello) is displayed in the subscriber’s window.

 

[ERROR]-[Enterprise Message Service]-What is the meaning of the following error: “ERROR: Slow clock tick xxx, delayed messaging and timeouts may occur”?

The error message “Slow clock tick xx, delayed messaging and timeouts may occur” was added in EMS 5.1.4 for defect #1-A35PT9 -The server can disconnect clients or other servers if it gets very busy such that it does not service incoming heartbeats within the server_timeout_client_connection or server_timeout_server_connection period.

The number xx indicates the delay when the timer thread is behind the current time, indicating that the EMS server has become busy.

The value of xx is the time difference in seconds.

This is an Informational message and is not detrimental to EMS, rather it is an indication that the EMS server is busy and delayed messaging and timeouts may occur.

Implementation of TIBCO EMS with the ELK Stack

Please Observe the you-tube video …….

Fault Tolerance Parameters in “tibemsd.conf ” file

ft_active

 

ft_active = URL

 
Specifies the URL of the active server.

If this server can connect to the active server, it will act as a backup server.

If this server cannot connect to the active server, it will become the active server.

ft_heartbeat

 
ft_heartbeat = seconds

 
Specifies the interval (in seconds) the active server is to send a heartbeat signal to the backup server to indicate that it is still operating. Default is 3 seconds.

ft_activation

 
ft_activation = seconds

Activation interval (maximum length of time between heartbeat signals) which indicates that active server has failed. Set in seconds: default is 10.

This interval should be set to at least twice the heartbeat interval.
For example: ft_activation = 60

Note: The ft_activation parameter is only used by the backup server after a fault-tolerant switchover.

The active server uses the server_timeout_server_connection to detect a failed server.

ft_reconnect_timeout

 
ft_reconnect_timeout = seconds

The amount of time (in seconds) that a backup server waits for clients to reconnect (after it assumes the role of primary server in a failover situation).

If a client does not reconnect within this time period, the server removes its state from the shared state files.

The ft_reconnect_timeout time starts once the server has fully recovered the shared state, so this value does not account for the time it takes to recover the store files.

The default value of this parameter is 60.