The Talon Manual

Versions Compared

Old Version 70

changes.mady.by.user Girish Mutreja

Saved on

compared with

New Version 71

changes.mady.by.user Girish Mutreja

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

When an outbound message is sent from within an application event handler, it is referred to as a solicited send. When an outbound message is sent from outside of a message handler, it is referred to as an unsolicited send. The steps listed above pertain to Solicited sends.

 

Note
titleUnsolicited Sends and Send Concurrency

In an application that only performs solicited sends, the X runtime ensures that the serialization and sends through the underlying transport are done in a single threaded manner. However, when an application performs unsolicited sends using two or more concurrent threads or performs unsolicited sends concurrently with solicited sends, then the sends through the underlying transport are performed using multiple concurrent threads. By default, the X runtime is not configured for thread safety for such concurrent sends. See Unsolicited Sends for more information on how to configure the X runtime to enable either or a combination of these concurrency scenarios.

...

Note

Sending a message through an AepEngine transfers ownership of the message to the engine. When a message is sent from within an application event handler, the application may not retain the message or any of its nested entities beyond the scope of the message handler as pooling may invalidate them.
Furthermore, unsolicited senders must consider sent messages to be immediately invalid because the sending thread is outside of the context of a transaction and can have no expectation as to when the platform will dispose of the message. An unsolicited sender may call acquire() on the message prior to sending it if it needs to hold onto the message for a period of time after sending, but it still may not modify or reuse.What this means is that, once the send call completes, the application must release its reference to the sent message. Modifying or even reading a message post send is illegal and can result in unpredictable behavior.

If a message is created, but not sent, it is up to the application to call dispose() on the message to return it the pool. Failing to return the message to a pool will not result in a memory leak, but it will mean that subsequent create() calls won't result in object allocation and promotion.

...